On Sun, Jan 17, 2010 at 11:20 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > Last week was a pretty annoying week for Solaris support. Two quite major > obstacles came up. > > 1) #7932: _Complex_I undeclared - a new bug totally stops a Solaris 10 > build. > > has introduced code which exploits a bug in gcc, which stops Sage building > on Solaris. This was particularly annoying, as 4.3.1 was expected to be the > first version to build easily on Solaris. But that rather put a stop to > that. > > > I notice Robert has included what he concedes is a 'hack' to disable the > code. I I've not bothered reviewing that yet, as there may be other ways > around this issue.
Robert explained this fix to us yesterday at Sage Days and it sounded pretty reasonable to me. William > The fixes to gcc are in the latest snapshots of the 4.5 release, but given > that is not due for several months, and the usual bugs in X.Y.0 releases of > gcc, I'm not very confident that will build Sage reliably. I've not tried I > must admit. I was a bit ****** off last week with all the hassles. I decided > to take a break for a few days. > > I intend contacting the author of the gcc patch, and asking him if there is > any chance of him back porting it to gcc 4.4.2, where it should be a bit > more reliable. I don't relish the thought of using a 4.5.0 snapshot, when > 4.5 is not due out for months. > > 2) Next there was the issue that my update to sage-env > > http://trac.sagemath.org/sage_trac/ticket/7818 > > caused problems. This would have allowed a much cleaner method of adding the > correct flags to compilers to generate 64-bit code on different platforms. > It would also have allowed performance improvements if one set CFLAGS to > optimise the compiler for their own platform, rather than let gcc develop > binaries for more basic compilers. (I realise some parts of Sage do pick > appropriate flags, but most do not, so there must be a performance impact). > > It would appear that by setting CFLAGS to -g -Wall, this inadvertently > removes the -fno-strict-aliasing option from the gcc options that Cython > uses to compile the auto generated C files. > > Given the vast majority of .spkg files in Sage could usefully use a common > set of options, it seems a bit of a shame. I feel the real solution to this > is to sort out Cython, so it either ignores the flags, or appends them to > its own choice of flags. (There's no reason -g or -Wall should be unsafe, > but clearly if they replace other flags, rather than get appended to, it > will cause issues). In my experience setting CFLAGS when they don't need to be set will cause major problems with anything that uses distutils (e.g., in the context of Cython above). In fact, numpy didn't get into Sage for a *long* time initially because your sage-env script by default set CFLAGS (to be empty, actually). This prevented numpy from building in the context of Sage. I only finally figured this out with help from some core numpy folks at a scipy conference.... (and you should have heard me swear at distutils!) > On a more positive note, Jaap Spies has taken an interest in porting Sage to > Open Solaris. That will certainly help. > > I've agreed to give a talk at the London Open Solaris User Group about Sage. > This will probably be on the 19th May. Hopefully there will not be too many > weeks like last week. We apologize for the inconvenience. You can have a free copy of Sage for your troubles. :-) -- William
-- 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
