On Apr 24, 3:03 am, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > Hi, > > One more thing about Solaris: The game plan of the Solaris port has > slightly changed. The initial port will be Solaris 10 and no longer > Solaris 9.
That seems sensible. Solaris 10 has been out a long while, so it does not seem unreasonable that someone upgrade to that - especially as it is free. The only downside of insisting on Solaris 10 is that it excludes some older 32-bit workstations, but I think anyone looking to make use of this sort of software on Solaris is likely to be using a 64-bit Sun. > The compiler I will use is Sun Fort 12 [or whatever cc 5.9 > corresponds to]. Sun studio 12 is a free download. kestrel /export/home/drkirkby % cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 usage: cc [ options] files. Use 'cc -flags' for details This is probably what you mean, which seems sensible to me. > The main reason is that the header situation with > Sun's compiler is much better and building even Python with Sun's > compiler in 64 bit mode is fairly trivial while doing so with gcc is a > huge pain when you actually want to use stuff like the md5 module. I'll take your word for that. > Additionally in most cases many installs have crap in /usr/local and > that really, really produces a lot of problems with gcc, while it > seems that with Sun's cc and CC I have much tighter control over that > issue. Yes. In any case, Sun's compiler is quite a bit quicker on Solaris SPARC than gcc. I suspect that is less so on x86, since the assembler code written will be much closer to that which was optimised on Linux. > On top of that dealing with the 32 vs. 64 bit issue on Solaris > [multilib is a really, really dumb idea, especially if you default to > 32 bit on as 64 bit platform - but I could bitch about that for hours, > so I will spare you the details] is something that seems to be less of > a problem with Sun's tool chain. > Apple's decision to do the exact same > kind of move doesn't bode to well, but at least they have universal > binaries/library support to lessen that blow. > > Oh well, porting sucks ;) Yes, it can do. I remember once having some code which worked on just about everything except a Cray. Then I found out why sizeof(short) == 8 on the Cray. That made life a bit hard, as I had to write the shorts as two separate characters. But it had the knock on advantage of removing endianness issues. At one time I used to run quite a collection of UNIX boxes for portability testing, including * Dec Alpha running Tru64 * HP workstation running HP-UX * IBM server running AIX * Suns running Solaris, NetBSD and Linux. * SGI Octane running IRIX * PC running linux * PC running Solaris x86 Whilst I don't have a Cray, I also tested it on a Cray. But I can't recall the last time much of that hardware was used. Anyway, if I can help with a Solaris port, I'm quite willing to. Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
