About the SAGE64 stuff, right now when the option is tested it basically sets the different C??FLAGS to -m64 -g -O2 As you pointed above I guess the -m64 forces gcc to produce 64 bits binaries even though the default is 32 bits, so I'm fine with that. I guess that the -g -O2 flags are set because that's what autoconf magically chooses on a "standard" system when the C??FLAGS are empty. Is everybody happy with that ? I mean that if at some point autoconf decides that different flags should be used, we will get different flags depending on whether SAGE64 is set or not. Of course, this will probably never happen... and getting the default flags would slow the building time of Sage.
On 9 fév, 00:59, William Stein <wst...@gmail.com> wrote: > On Wed, Feb 8, 2012 at 3:46 PM, Dr. David Kirkby > > > > > > > > > > <david.kir...@onetel.net> wrote: > > On 02/ 8/12 09:11 PM, Jeroen Demeyer wrote: > > >> On 2012-02-08 16:37, David Kirkby wrote: > > >>> Unfortunately, due to what appears to be a bug with Pynac, importing a > >>> lot of python modules, 64-bit binaries on Solaris do not run well. > > >> So, if I understand you correctly, Sage *builds* but it doesn't actually > >> work properly? I actually meant "builds and runs as it should" with > >> SAGE64=yes in my original question. > > > I believe Sage builds and runs as it should on some older releases of OS X, > > where the default was to build 32-bit binaries. So if you want to test it, > > find out what versions of OS X have this property, and test on that. > > > SAGE64 was first introduced when Micheal decided to port Sage to OS X - > > Minor correction: he was getting Sage to build on OS X as a 64-bit > application. Sage already built and ran fine as a 32-bit program on > OS X. With OS X 10.5, the default with gcc was to generate 32-bit > code, so building 64-bit meant passing various flags at the right > places. > > >>> So unless someone comes up with something better, I think SAGE64 should > >>> not be altered. > > >> My main problem is testing SAGE64. If some new spkg breaks a SAGE64 > >> build, nobody is going to notice. Most authors and reviewers (including > >> me) are unable to test whether SAGE64 really works. > > > I believe William is going to switch on t2.math. In which case, you can test > > Yes. The math dept now has the whole server room to ourselves. > > > the building on that. However, Sage wont run properly until someone fixes > > the fact Pynac is calling modules which are not initialised > > >http://trac.sagemath.org/sage_trac/ticket/11116 > > > So unless the pynac issue is resolved, the best you can do on Solaris SPARC > > is test Sage builds with SAGE64 set to yes. (R still presents a problem on > > 64-bit Solaris x86). > > > But on OS X, this should be easy to test - assuming you can find the > > hardware with a sufficiently old version of OS X > > 10.5 > > > > > > > > > > > > >> Jeroen. > > > -- > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > A: Top-posting. > > Q: What is the most annoying thing in e-mail? > > > -- > > 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 > > URL:http://www.sagemath.org > > -- > William Stein > Professor of Mathematics > University of Washingtonhttp://wstein.org -- 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 URL: http://www.sagemath.org
