On Sep 16, 9:13 pm, "didier deshommes" <[EMAIL PROTECTED]> wrote: > 2007/9/16, mabshoff <[EMAIL PROTECTED]>:
Hello Didier, > > > it looks like you are running a fairly recent OpenSolaris build. But > > is it "pure" OpenSolaris or Nexenta? I know you used Nexenta in the > > past, but that is quite different because the userspace is close to > > 100% GNU while Solaris is sufficiently different to cause issues. I > > run the latest official Solaris 10 U4: > > It is pure Solaris. More specifically this is "Solaris Express > Community Edition b57". The only modifications I made is that I use > gnu build tools whenever I can (ie gmake, gcc, gas, ranlib, tar, etc). > I hope that answers your question. > Pretty much. I saw that you ran the nevada kernel and build 57. I never ran Nexenta, but now found out that its uname does mention it and the blaswave packages do not run on it. But Solaris Express seems to be a lot more current than Solaris 10, just look at the difference between Solaris 9 and 10 to get an idea many problems just vanish between those two releases. Regarding the GNU tools: I installed those from the official Solaris 10 DVD and then build my own environment. I am curious if my issues will go away with Solaris Express, but I still need to be able to build on 9 & 10. For example: the math department at Dortmund they still runs Solaris 9 on all Sparc hardware and there are no plans to introduce 10, much less run Solaris Express. Only recently the Solaris 8 boxen were upgraded, so Solaris installations have a tendency to stick around quite some time (which shouldn't come as a surprise to anybody who ever worked on/with Solaris - if it ain't broken, don't fix it) I don't think we should support Sage in Solaris/x86 on anything older but 10, but for Sparc support for 9 would be good. > > > uname -a > > SunOS unknown 5.10 Generic_120012-14 i86pc i386 i86pc > > > > ~/custom/sage-2.8.4.2 $ gcc -v > > > Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs > > > Target: i386-pc-solaris2.8 > > > Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 > > > --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas > > > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix > > > --enable-shared --enable-multilib --enable-nls --with-included-gettext > > > --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib > > > --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada > > > Thread model: posix > > > gcc version 4.0.2 > > > > I am using pre-compiled packages from blastwave. > > > " --enable-threads=posix" might take care of some of the python issue. > > I have seen python 2.5.1 at blastwave.org, so I assume it is possible > > to build it without too much fiddling. William and I wanted to build > > everything from source without the need to install external packages. > > And we are trying to also get it to work in Solaris 9. > > > Haven't seen that one. But it is a GMP symbol and I have no idea why > > that would be linked against Lapack. The BlastWave binary also seems > > to have been compiled for Solaris 2.8, so that might be an issue. > > Come to thinks about it, I think the gfortran lapack package installs > mpfr (or gmp I can't remember) with it. The solution might as simple > as grabbing the gfortran binary for x86-solaris and installing it > manually. > Sounds like the solution. I really dislike the fact that pkgadd cannot deal with dependencies properly. But it is common practice to statically link gmp & mpfr against any gcc compiler, 4.2. actually warns you about dynamic libraries if I recall correctly. > didier > > 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
