William Stein wrote: > On Tue, Aug 11, 2009 at 9:17 PM, David Kirkby<david.kir...@onetel.net> wrote: >> 2009/8/12 William Stein <wst...@gmail.com>: >>> On Tue, Aug 11, 2009 at 7:38 PM, Robert >>> Bradshaw<rober...@math.washington.edu> wrote: >>>> On Aug 11, 2009, at 1:42 PM, Dr. David Kirkby wrote: >>>> >>>>> I gather that what gcc works on OS X depends on many things. Can >>>>> anyone >>>>> be precise about exactly what works and what does not? I can do some >>>>> semi-sensible testing in a configure script if I knew what was wanted, >>>>> but I don't. >>>>> >>>>> I have at this point put a test in for gcc version >>>>> >>>>> minimum_gcc_version="4.0.1" >>>>> >>>>> # Exit if the version of GCC is known to be too old >>>>> AS_VERSION_COMPARE([$GCC_VERSION], [$minimum_gcc_version],[ >>>>> AC_MSG_WARN([GCC $GCC_VERSION is too old and can not build >>>>> AC_PACKAGE_NAME. Please use]) >>>>> AC_MSG_WARN([a gcc of at least $minimum_gcc_version. )]) >>>>> AC_MSG_ERROR([Exiting due to the use of a version of GCC that >>>>> is too old]) >>>>> ], [],[]) >>>>> >>>>> >>>>> But from what I gather, having 4.0.1 on OS X is no guarantee of >>>>> success. >>>> IIRC, 4.0.1 is the latest (default) compiler that ships with OS X, >>>> and it seems to work for a lot of us. >>> Where were some reports you may have missed oon sage-*f many default >>> builds of 4.0.1 for OS X *not* working if one upgrades to the latest >>> version of OS X. One needs a relatively recent version of XCode. >>> >>>>> The best thing to do would be to check for particular compiler >>>>> features, >>>>> rather than versions, as that is more portable. But from a practical >>>>> point of view, I doubt anyone know what feature is missing in older >>>>> versions on OS X this is needed. >>>> >>>> The "missing features" is 4.0.0 (vs 4.0.1) are a pile of bugfixes. >>>> Sage exposes a lot of bugs in 4.0.0 but compiles fine with 4.0.1. >>>> >>>> IIRC, the 3.4+ was for sufficient c99 support, but someone else >>>> probably knows better. >>> Yes, it was. But when Robert Miller included Stoll's ratpoints spkg, >>> sage suddenly no longer built with 3.4. >>> >>> William >> Do you know what feature is needed that some older XCodes will not >> have? If for example, the reason older ones would not work as the >> sizeof(long long) was not 8, then I could check for that. > > This reminds me of a quote from the excellent movie "The Hurt Locker": > > Colonel Reed: What's the best way to go about disarming one of these > things? [In reference to an IED in Iraq.] > > Staff Sergeant William James: The way you don't die, sir. > > If I remember correctly, the problem with many old(er) versions of > XCode is that they give "Internal compiler error" somewhere deep in > the Sage build.... > >> Would someone on OS X running gcc >=4.0.2 need to update Xcode? >> >> In the absence of better information, I could just put a warning on OS >> X that using the latest Xcode is strong advised, with a link to >> http://developer.apple.com/TOOLS/Xcode/ > > That seems very reasonable. However, it is known and was reported on > sage-devel very recently that certain specific *builds* of Xcode don't > work. > When you do "gcc -v" with xcode this is what happens: > > w...@bsd:~$ gcc -v > Using built-in specs. > Target: i686-apple-darwin9 > Configured with: /var/tmp/gcc/gcc-5465~16/src/configure > --disable-checking -enable-werror --prefix=/usr --mandir=/share/man > --enable-languages=c,objc,c++,obj-c++ > --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ > --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib > --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic > --host=i686-apple-darwin9 --target=i686-apple-darwin9 > Thread model: posix > gcc version 4.0.1 (Apple Inc. build 5465) > > You pretty much always get "4.0.1" as the version, but the build > numbers very widely. I'm actually surprised to see build 5465 on bsd > above, since I upgraded Xcode on there yesterday. Weird. I must > have messed up. > > On my laptop I get: > > flat:~ wstein$ gcc -v > Using built-in specs. > Target: i686-apple-darwin9 > Configured with: /var/tmp/gcc/gcc-5490~1/src/configure > --disable-checking -enable-werror --prefix=/usr --mandir=/share/man > --enable-languages=c,objc,c++,obj-c++ > --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ > --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib > --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic > --host=i686-apple-darwin9 --target=i686-apple-darwin9 > Thread model: posix > gcc version 4.0.1 (Apple Inc. build 5490) > > For the record, I just tested and for me Sage builds fine with the > xcode on bsd.math. However this test regularly fails: > > sage -t -long "devel/sage/doc/en/bordeaux_2008/birds_other.rst" > > This is because of a compiler bug. Some multithreaded code for David > Harvey for computing Bernoulli numbers spontaneously fails every so > often. It's definitely a compiler bug, and using a newer compiler > gets rid of this bug. > > Anyway, it seems like we should do something like print a huge warning > and an interactive "are you sure you want to continue? [yes/no]" if > the > "(Apple Inc. Build xxxx)" has xxxx < some_arbitrary_number, where the > arbitrary number is something like say 5470? > > -- William
You would not happen to have a small snipit bit of code that can reproducibly generate the error would you? (I guess the answer is no, but there is no harm in asking). If so, actually compiling that code and testing it in autoconf would be good. It is not normal to have "Are you sure yes/no" in configure scripts, which was what I was working on (i.e. configure.ac). The only options in cases like this I'm aware of are 1) Issue a warning (AC_MSG_WARN) 2) Issue an error (AC_MSG_ERROR), which exits. Given the tools are available free, then exiting might be best. If I exit with a message: "If you are really insistent on trying to build Sage with tools known to be broken, set the variable SAGE_USE_BROKEN_TOOLS to 1" That I think would be easiest to implement, rather than a yes/no. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
