#11278 closed defect (fixed)
singular 3-1-1-4.p8 fails on Mac OS X 10.4
Reported by: | jdemeyer | Owned by: | tbd |
---|---|---|---|
Priority: | blocker | Milestone: | sage-4.7 |
Component: | packages: standard | Keywords: | |
Cc: | Merged in: | sage-4.7.rc2 | |
Authors: | Jeroen Demeyer | Reviewers: | Karl-Dieter Crisman |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
On my Mac OS X 10.4 PPC 32-bit system, singular (#11084) fails to compile with -O2 while it does work with -O3. This is the relevant part from the log file:
g++ -O2 -g -fPIC -pipe -fno-implicit-templates -I. -I../kernel -I/Users/jdemeyer/sage-4.7.rc0/local/include -I/Users/jdemeyer/sage-4.7.rc0/local/include -I/Users/jdemeyer/sage-4.7.rc0/local/include -DNDEBUG -DOM_NDEBUG -DppcMac_darwin -DHAVE_CONFIG_H -c mpsr_Tok.cc libtool -dynamic -twolevel_namespace -weak_reference_mismatches weak -undefined dynamic_lookup -single_module -o libsingular.dylib \ libsingular-tesths.o iparith.o mpsr_Tok.o claptmpl.o \ grammar.o scanner.o attrib.o eigenval_ip.o extra.o fehelp.o feOpt.o ipassign.o ipconv.o ipid.o iplib.o ipprint.o ipshell.o lists.o sdb.o fglm.o interpolation.o silink.o subexpr.o janet.o wrapper.o libparse.o sing_win.o gms.o pcv.o maps_ip.o walk.o walk_ip.o cntrlc.o misc_ip.o calcSVD.o Minor.o MinorProcessor.o MinorInterface.o slInit_Static.o mpsr_Put.o mpsr_PutPoly.o mpsr_GetPoly.o mpsr_sl.o mpsr_Get.o mpsr_GetMisc.o mpsr_Error.o ndbm.o sing_dbm.o -lkernel -L../kernel -L../factory -L../libfac -L/Users/jdemeyer/sage-4.7.rc0/local/lib -lsingfac -lsingcf -lntl -lreadline -lgmp -lomalloc ld: for architecture ppc ld: ../kernel/libkernel.a(matpol.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: restFP saveFP libtool: internal link edit command failed make[3]: *** [libsingular] Error 1 make[2]: *** [libsingular] Error 2 Unable to build Singular.
Googling for restFP/saveFP seems to indicate it is a known problem when mixing compilers, see for example http://lists.apple.com/archives/fortran-dev/2004/jul/msg00036.html
New spkg using -O3 on gcc 4.0.x: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-1-4.p9.spkg
Attachments (1)
Change History (24)
comment:1 Changed 10 years ago by
- Description modified (diff)
- Summary changed from Add -finline-functions to singular CFLAGS to singular 3-1-1-4.p8 fails on Mac OS X
comment:2 Changed 10 years ago by
- Description modified (diff)
comment:3 Changed 10 years ago by
- Summary changed from singular 3-1-1-4.p8 fails on Mac OS X to singular 3-1-1-4.p8 fails on Mac OS X 10.4
comment:4 Changed 10 years ago by
- Description modified (diff)
comment:5 Changed 10 years ago by
comment:6 follow-up: ↓ 9 Changed 10 years ago by
Dave, it's clear from reading various posts about this problem that it is an Apple-specific issue, so I doubt the Solaris stuff you linked to is relevant.
I'm using these compilers:
$ gcc --version powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ --version powerpc-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
comment:7 Changed 10 years ago by
- Status changed from new to needs_info
Google suggests that this is xcode-2.4.1. Can you try with a later xcode release? I think anything up to the latest xcode-3 supports PPC OSX 10.4.
comment:8 follow-up: ↓ 10 Changed 10 years ago by
Hi,
for Mac OS X 10.4 (Tiger), one should update to the latest OS version (10.4.11), and use the latest XCode version which is supported by OS X 10.4, this is XCode v2.5 (already some years old). It comes with a "build 5370" Apple version of GCC 4.0.1. (Any later XCode versions are not supported for OS X 10.4, AFAIR.)
I'll give Sage-4.7.rc1 a try on both my OS X 10.4 MacIntel? and MacPPC boxes, but the latter will literally need days to give results (it's got a 7440 G4 @ 550MHz CPU).
comment:9 in reply to: ↑ 6 Changed 10 years ago by
Replying to jdemeyer:
Dave, it's clear from reading various posts about this problem that it is an Apple-specific issue, so I doubt the Solaris stuff you linked to is relevant.
I would still not dismiss the possibility that there might be non-PIC code being generated.
Dave
comment:10 in reply to: ↑ 8 Changed 10 years ago by
Replying to GeorgSWeber:
I'll give Sage-4.7.rc1 a try on both my OS X 10.4 MacIntel? and MacPPC boxes, but the latter will literally need days to give results (it's got a 7440 G4 @ 550MHz CPU).
Thanks! Those will be useful data points.
comment:11 Changed 10 years ago by
Just got in to work, I am now downloading and it will probably get to Singular sooner rather than later, we'll see.
Georg is correct that no version >2.5 is supported on 10.4. I also only have build 5367/Xcode 2.4.1, but will see if I can track down Xcode 2.5 later - that might not mean immediately.
comment:12 Changed 10 years ago by
On the system where the problem was discovered: -O0 also does work.
So here is a proposal: on "old" (4.0.x) versions of gcc: use -O3, otherwise -O2. That would fix the problem on this ticket.
comment:13 Changed 10 years ago by
- Description modified (diff)
- Status changed from needs_info to needs_review
comment:14 follow-up: ↓ 15 Changed 10 years ago by
Just a comment (hopefully I'll be able to review at all - even with the Xcode update, I still can't get past PolyBoRi) - any reason for checking this, rather than uname=Darwin and then the Xcode version/gcc version? Have we had any complaints on other platforms for gcc 4.0.x?
comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 10 years ago by
Replying to kcrisman:
Have we had any complaints on other platforms for gcc 4.0.x?
There were no complaints on other platforms as far as I know. However, you can consider the situation with gcc 4.0.x a status-quo: it used to be -O3 before rc0, and it is now again -O3. Since there were no problems with gcc 4.0.x before rc0, I don't think it is a problem to use -O3 with gcc 4.0.x on all platforms.
comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 10 years ago by
- Reviewers set to Karl-Dieter Crisman
Replying to jdemeyer:
Replying to kcrisman:
Have we had any complaints on other platforms for gcc 4.0.x?
There were no complaints on other platforms as far as I know. However, you can consider the situation with gcc 4.0.x a status-quo: it used to be -O3 before rc0, and it is now again -O3. Since there were no problems with gcc 4.0.x before rc0, I don't think it is a problem to use -O3 with gcc 4.0.x on all platforms.
Okay, that makes sense. Positive review on the diff, and presumably this would fix it if it worked before; however, it will still take a while until I can test it because of the unrelated build issue mentioned above, so if someone else beats me to it, by all means.
I am going to try to build rc0, not rc1; if I can get that to build up to Singular, then replace with this, I think that would be enough for positive review.
comment:17 in reply to: ↑ 16 ; follow-up: ↓ 18 Changed 10 years ago by
Replying to kcrisman:
I am going to try to build rc0, not rc1; if I can get that to build up to Singular, then replace with this, I think that would be enough for positive review.
How is it working out?
comment:18 in reply to: ↑ 17 ; follow-up: ↓ 19 Changed 10 years ago by
Replying to jdemeyer:
Replying to kcrisman:
I am going to try to build rc0, not rc1; if I can get that to build up to Singular, then replace with this, I think that would be enough for positive review.
How is it working out?
I think I said somewhere on the rc1 sage-release list that rc0 failed at the same place in PolyBoRi. I will try to look into that more (the sed thing) when I'm done with classes today, but until then there isn't much I can do with this, except to ./sage -f it into an alpha5 and check that it builds.
Maybe I could try to ./sage -f the 'bad' one into my alpha5, check it fails, and then ./sage -f this one into my alpha5, check that it builds. Would that be sufficient? I think I do have the ability to try that.
comment:19 in reply to: ↑ 18 ; follow-up: ↓ 20 Changed 10 years ago by
Replying to kcrisman:
Maybe I could try to ./sage -f the 'bad' one into my alpha5, check it fails, and then ./sage -f this one into my alpha5, check that it builds. Would that be sufficient? I think I do have the ability to try that.
Let's try that then.
comment:20 in reply to: ↑ 19 Changed 10 years ago by
- Status changed from needs_review to positive_review
Replying to jdemeyer:
Replying to kcrisman:
Maybe I could try to ./sage -f the 'bad' one into my alpha5, check it fails, and then ./sage -f this one into my alpha5, check that it builds. Would that be sufficient? I think I do have the ability to try that.
Let's try that then.
Success! Failed with p8, worked with p9. I'm now waiting on ./sage -b, but don't anticipate any problems if you didn't have any. I'll revert the positive review if I do come up with any problems, otherwise it's good to go.
comment:21 Changed 10 years ago by
Yeah, relevant tests are all passing. Good sleuthing.
comment:22 Changed 10 years ago by
- Merged in set to sage-4.7.rc2
- Resolution set to fixed
- Status changed from positive_review to closed
comment:23 Changed 10 years ago by
Sorry for the delay, just to let you know:
On my MacPPC system, OS X 10.4.11 with XCode 2.5, with an older G4 CPU with 550 MHz and 768 MB RAM, Sage-4.7.rc2 (with singular 3-1-1-4.p9) builds fine! For some (more or less unrelated) details about polybori, see my comments trac #11331.
What version of gcc is this failing with? I assume it is not 4.6.0, but can you confirm that?
This error message reminds me of ones that existed with R and ECL on Solaris. The ECL bug has been fixed, but not the R bug (#9040), so R will not build 64-bit on Solaris x86 with gcc. The R bug is caused by a shared library being built with position dependent code. There are some conditions that can cause non-PIC code to be generated even when the flag -fPIC is given.
I would check if -fPIC is being passed first. I had a long battle with the Singular developers to get them to accept that -fPIC should be used on Solaris. I think I'd convinced them on Linux too, but never tried on OS X. It could be that there's no -fPIC flag and it just happens this is ok with -O3 but not with -O2.
Take a look at
http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
which discusses this issue. It is a Sun blog aimed at Solaris, but the error message seems remarkably similar. Which makes me think this might be a PIC/non-PIC issue.
Time for bed here - it is 0300 local time!!
dave