On Apr 25, 12:52 pm, "Dr. David Kirkby" <[EMAIL PROTECTED]>
wrote:
> On Apr 24, 3:03 am, mabshoff <[EMAIL PROTECTED]
>
> dortmund.de> wrote:
> > Hi,
Hi David,
> > 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.
Yeah, it seems that most people stuck around with Solaris 8 while many
shops went on to Solaris 10.
> 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.
If you want to do HPC like stuff I am sure there aren't too many 32
bit boxen around to do that. I am unaware of anybody running 32 bit
only Sparc hardware for anything but nostalgic reasons.
> > The compiler I will use is Sun Fort 12 [or whatever cc 5.9
> > corresponds to].
>
> Sun studio 12 is a free download.
Yes. Even though Sun's idiotic registration policy always annoyed me.
There was a blog by Ted Tso linked from slashdot yesterday talking
about Sun & Open Source regarding the OpenSolaris kernel and I mostly
have to agree with him. When I first downloaded and installed Solaris
10 to run on my personal hardware I was unable to pull upgrades to
Solaris 10 after *registration* because some of their authentication
server were down. Were I not in the game of porting Sage to Solaris
the career of Solaris on my hardware would have been over at that
point and I would have wiped it off my hardware for that idiotic
policy alone. pkg_add & friends are a joke, but I am not here to rant
and bitch about Solaris ;)
> 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.
Yep.
> > 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.
The current OpenSSL release for example uses the wrong flags even when
compiled with the Sun Forte compiler. It is a sad, sad world.
> > 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.
It isn't so much performance itself, but the fact that gcc's headers
suck. ;)
> > 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
hehe, I never had the pleasure of porting to Cray.
> 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
I have access, but why bother. It ought to be dead by now.
> * HP workstation running HP-UX
We have been thinking of somebody buying us a Itanium box running HP-
UX, but I would classify that as exotic hardware.
> * IBM server running AIX
On the list for Sage
> * Suns running Solaris, NetBSD and Linux.
> * SGI Octane running IRIX
Somebody asked about some build problems on IRIX off list, so we might
be able to get an account somewhere. There are certainly still some
rather large MIPS/IRIX boxen around and it would be fun to port Sage
to them.
> * 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.
Thanks a lot. My porting timetable for now is:
3.0.1/3.0.2: 64 bit OSX 10.5 support, FreeBSD support - the FreeBSD
support will remove the last GNUism from the various places I am aware
of.
3.1: New coercion code by the coercion team. Since there currently are
some issues with coercion on Sparc that will hopefully be fixed by the
new code I see no reason to do something about those problems in the
3.0 codebase and will tackle Solaris in earnest only once that code is
merged.
3.1+: Start add build support for the Sun Forte compiler to spkg-
install in places where it is needed. Quite a bunch of packages assume
or hard code the compiler as g++/gcc as obseved by Gonzalo. Since I am
doing cleanup for the 10.5 64 bit support anyway I might start adding
build support for Sun Forte while doing those cleanups.
> Dave
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
