Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#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 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

Attachments (1)

singular-3-1-1-4.p8-p9.diff (1.9 KB) - added by jdemeyer 9 years ago.
Diff for the singular spkg, for reviewing only

Download all attachments as: .zip

Change History (24)

comment:1 Changed 9 years ago by jdemeyer

  • 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 9 years ago by jdemeyer

  • Description modified (diff)

comment:3 Changed 9 years ago by jdemeyer

  • 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 9 years ago by jdemeyer

  • Description modified (diff)

comment:5 Changed 9 years ago by 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

comment:6 follow-up: Changed 9 years ago by 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.

comment:7 Changed 9 years ago by vbraun

  • 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: Changed 9 years ago by 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).

comment:9 in reply to: ↑ 6 Changed 9 years ago by 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

comment:10 in reply to: ↑ 8 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by 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.

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Description modified (diff)
  • Status changed from needs_info to needs_review

Changed 9 years ago by jdemeyer

Diff for the singular spkg, for reviewing only

comment:14 follow-up: Changed 9 years ago by 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?

comment:15 in reply to: ↑ 14 ; follow-up: Changed 9 years ago by 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.

comment:16 in reply to: ↑ 15 ; follow-up: Changed 9 years ago by kcrisman

  • 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: Changed 9 years ago by 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?

comment:18 in reply to: ↑ 17 ; follow-up: Changed 9 years ago by 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.

comment:19 in reply to: ↑ 18 ; follow-up: Changed 9 years ago by 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.

comment:20 in reply to: ↑ 19 Changed 9 years ago by kcrisman

  • 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 9 years ago by kcrisman

Yeah, relevant tests are all passing. Good sleuthing.

comment:22 Changed 9 years ago by jdemeyer

  • Merged in set to sage-4.7.rc2
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:23 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.