Robert Bradshaw wrote: > On Sep 29, 2009, at 11:55 AM, David Joyner wrote: > >> Thanks for working on this. >> >> What more needs to be tested? The install went fine on an intel >> macbook running 10.6. >> >> Maybe Robert Bradshaw should comment on it, since he wrote >> rubik.py? > > OK, I'll bite. > > I simply took the three individual packages and put them all into the > same spkg. I'm no build guru, so I mostly left the make scripts, etc. > as they were, and they compiled and worked on all (at the time) > supported platforms. I am sure the authors were not targeting > Solaris, let alone their compiler, or maybe not even anything beyond > their own personal machines. The makefiles have since been edited > many times, looks like you were careful so hopefully all issues are > finally sorted out. > > I do have to ask, fortran flags? I know there's no fortran in there. > Also, the lack of -m64 doesn't imply 32-bit, does it? And why O2 > rather than O3? > > - Robert
Hi Robert, thank you for biting! First I have had about 5 pints of beer tonight, so bear this in mind! I've tried to create a spkg-install which will work properly on almost any package, with the hope of providing some measure of standardisation. At the minute, lots of different spkg-install's exist, and some seem pretty poor to me. I think it is better if we could have a basic spkg-install, which set up most things, then the producer of a .spkg just needed to consider specific issues with their package. As such, I've set all flags, including those for Fortran, even when not needed. The extra few bytes of code does no significant harm. If the package does not use Fortran, then it will ignore the Fortran flags. The problem with creating a spkg-install with a subset of things set, is that the subset needs carefully testing for each package. My version might waste a couple of KB bytes, but it is safe. So I have tended to write spkg-install's in such a way that they should work with any package. Minh asked me the other day to write this up, though I chose not to just now, as I am not convinced my latest version is as good as possible. A lack of the ability to add -m64 does on some platforms mean it is not possible to build 64-bit code. Solaris is such a platform. All Solaris machines made in the last 10 years or so are 64-bit, but Sun still by default build binaries 32-bit. This is sensible, as pointers are smaller, more can fit in the cache etc. There are certainly disadvantages to 64-bit code. Likewise I believe on OS X, The fact SAGE64 was not used in rubiks, made it impossible to create a 64-bit binary rubiks on OS X. Since the aim is to ultimately produce a Sage capable of 64-bit, then the SAGE64 variable needs to be handled correctly. One could reasonably argue that some part of Sage benefit from 64-bit, and others do not. I know at one point Mathematica's kernel on Solaris was 64-bit, but the front end was 32-bit, simply since Wolfram Research rightly realised there were disadvantage, and no significant advantages to having a 64-bit front end. But my belief is that Sage should be build either 32-bit or 64-bit, and not a mix of the two. (If others feel differently, say so). If we are going to mix the two, then there needs to be a big discussion about what bits of Sage are to be 64-bit and what bits are to be 32-bit. It's easier to make all Sage 32-bit or all Sage 64-bit in my opinion. That means all packages must consider the variable SAGE64. As for -O2 vs -O3, the spkg-install says: # Add a sensible default optimisation flag. Change if necessary. OPTIMIZATION_FLAGS="-O2" Without a lot of care taken to * Look at the code * Check exactly what -O3 does for every compiler * Extensive testing I don't think it is safe to assume -O3 will be safe and not create a problem. One of the troublesome packages I noticed when testing with Sun Studio is tachyon, which uses -O6. http://sagetrac.org/sage_trac/ticket/7069 It's not the -O6 which is causing the Solaris problem, though I do think -O6 is unwise. The fact that the tachyon.spkg ignores CC and uses gcc anyway, makes me believe the code is not well thought out. Therefore I suspect there has not been extensive testing to prove -O6 is safe. The problem with the more aggressive optimisations is that they can lead to inaccurate assembly code, as compiler makes assumptions which are not true. I believe at -O2, the assembly code will be ok. I don't think that is necessarily true at -O3. While -O3 might be safe, unless someone is going to test it, then I think its unwise to use -O3. Dave. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
