singular 3-1-1-4.p8 fails on Mac OS X 10.4

[jdemeyer]

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

[drkirkby]

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

[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'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.

[vbraun]

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.

[GeorgSWeber]

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).

[drkirkby]

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

[jdemeyer]

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.

[kcrisman]

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.

[jdemeyer]

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.

[jdemeyer]

Diff for the singular spkg, for reviewing only

[kcrisman]

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?

[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.

[kcrisman]

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.

[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?

[kcrisman]

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.

[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.

[kcrisman]

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.

[kcrisman]

Yeah, relevant tests are all passing. Good sleuthing.

[GeorgSWeber]

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.