Opened 12 years ago
Closed 11 years ago
#9379 closed defect (duplicate)
ia64-Linux binary fails "devel/sage/sage/plot/plot3d/tachyon.py"
Reported by: | mariah | Owned by: | Mariah Lenox |
---|---|---|---|
Priority: | critical | Milestone: | sage-duplicate/invalid/wontfix |
Component: | packages: standard | Keywords: | |
Cc: | jason, jeroen | Merged in: | |
Authors: | Reviewers: | Volker Braun | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Sage built on skynet/cleo (ia64-Linux-rhel) fails the following test when run on skynet/iras (ia64-Linux-suse):
./sage -t -long "devel/sage/sage/plot/plot3d/tachyon.py"
The reason is because tachyon is being built with cc rather than gcc.
The attached mercurial patch causes tachyon to be built with gcc rather than cc.
Attachments (2)
Change History (20)
Changed 12 years ago by
comment:1 Changed 12 years ago by
- Status changed from new to needs_review
comment:2 Changed 12 years ago by
- Summary changed from is64-Linux binary fails "devel/sage/sage/plot/plot3d/tachyon.py" to ia64-Linux binary fails "devel/sage/sage/plot/plot3d/tachyon.py"
comment:3 follow-up: ↓ 4 Changed 12 years ago by
comment:4 in reply to: ↑ 3 Changed 12 years ago by
- Status changed from needs_review to needs_work
Replying to was:
It might be better to somehow use the CC environment variable!
flat:~ wstein$ sage -sh Starting subshell with Sage environment variables set. Be sure to exit when you are done and do not do anything with other copies of Sage! Bypassing shell configuration files ... /Users/wstein sage subshell$ echo $CC gcc /Users/wstein sage subshell$
Yes, I would agree - using of the CC environment variable would be preferable.
If $(CC) does not work, try ${CC}. The target does not have 'gcc' in the name, so there is no reason to hard-code gcc.
Dave
comment:5 Changed 12 years ago by
- Status changed from needs_work to needs_review
Here is an updated patch trac9377.patch and the corresponding tachyon-0.98beta.p12.spkg spkg.
comment:6 Changed 11 years ago by
While testing this with 4.6.1.rc0
on cleo I ran into an internal compiler error building pari. A workaround is using the updated pari package at #10430. (Thanks to jdemeyer for the pointer.)
comment:7 Changed 11 years ago by
This looks good to me, and I tested the spkg to confirm it fixed the issue.
Possibly it would be a good idea to remove some more of the "CC=..."
statements (there are *many*) from Make-arch
, but it's hard to say for which ones it would be useful. The only ones currently used by sage that set CC
to cc
instead of gcc
are macosx
and macosx-64
, in any case.
Any opinions? (Remove all of them? Remove all the ones used by sage? Remove only those for macosx and macosx-64? Leave it as it is now?)
comment:8 in reply to: ↑ description Changed 11 years ago by
- Status changed from needs_review to needs_info
Replying to mariah:
Sage built on skynet/cleo (ia64-Linux-rhel) fails the following test when run on skynet/iras (ia64-Linux-suse):
./sage -t -long "devel/sage/sage/plot/plot3d/tachyon.py"
The reason is because tachyon is being built with cc rather than gcc.
Is this really true? I would like to know how using a different compiler can cause a doctest to fail. What is the doctest error? Maybe changing cc
to gcc
fixes the issue, but is that really the right fix?
comment:9 Changed 11 years ago by
Running the tachyon built with cc on cleo causes a floating point exception on startup on iras. (Even when running tachyon without parameters to get the help.)
Incidentally 'cc' is also gcc on cleo, but a different one than the gcc in the PATH.
comment:10 Changed 11 years ago by
Any idea why the FPE only happens on iras and not on cleo itself? Could it be that iras has a slightly incompatible processor in which case moving a binary from cleo to iras is simply something one shouldn't do?
comment:11 Changed 11 years ago by
From looking at the /proc/cpuinfo output, it seem that they have exactly the same processor (same stepping, even). The only difference is that iras runs a slightly older kernel that doesn't know yet a textual representation of family=32.
comment:12 Changed 11 years ago by
The issue is that binaries compiled on cleo with cc contain a .gnu.hash
ELF section (the "new" type), while the dynamic linker on iras only understands .hash
ELF sections (the "old" type).
Compiling on cleo with cc and -Wl,--hash-style=both
produces binaries that also work on iras.
But this is just background info, and not related to the real bug of overriding CC in tachyon's build system.
comment:13 Changed 11 years ago by
- Status changed from needs_info to needs_work
During the status reports for Sage Days 27 yesterday, we decided that we should probably not override CC on any platform.
comment:14 follow-up: ↓ 16 Changed 11 years ago by
- Status changed from needs_work to needs_review
I checked that tachyon is the only package that actually calls cc
(by placing a non-working cc
in the path). So thats good, at least only one place to clean up.
The gcc wrapper from #10572 automatically
- calls gcc when cc is invoked, and
- adds the
--hash-style=both
option.
I double checked that this allows one to build tachyon
on cleo, copy tachyon
to iras, and successfully doctest on iras.
Nevertheless, we should fix the Tachyon Make-arch
to not overwrite $CC
. Its build system is somewhat baroque, but I made changed all GNU compiler targets to not override $CC
, $AR
, and $RANLIB
. All of these variables are already provided in the Sage environment. For the record, I will attach a copy of Make-arch
to this ticket.
But while we are at it, we should update to the newest upstream package. This ticket will be resolved by #5281.
comment:15 Changed 11 years ago by
- Cc jason added
comment:16 in reply to: ↑ 14 Changed 11 years ago by
Replying to vbraun:
The gcc wrapper from #10572 automatically
- calls gcc when cc is invoked, and
- adds the
--hash-style=both
option.I double checked that this allows one to build
tachyon
on cleo, copytachyon
to iras, and successfully doctest on iras.
Be careful. Both Intel and Sun/Oracle? produce compilers for x86 that are not called 'gcc'. On other platforms compilers can have all manner of names - aCC is one I can think of.
Dave
comment:17 Changed 11 years ago by
- Cc jeroen added
comment:18 Changed 11 years ago by
- Milestone changed from sage-4.6.2 to sage-duplicate/invalid/wontfix
- Resolution set to duplicate
- Reviewers set to Volker Braun
- Status changed from needs_review to closed
It might be better to somehow use the CC environment variable!