Open Solaris build Tools
Dr. David Kirkby
a Sun Ultra 27 (Intel Xeon, not SPARC).
I don't know the best configuration of the build tools, but have something seem
as though they will allow progress to be made. In contrast Jaap seems to have
some problems I've since solved.
I've put binary copies of gcc, binutils and OpenSSL in
http://boxen.math.washington.edu/home/kirkby/Open_Solaris_Build_Tools/
I used the lzma compression (p7zip on Solaris), as I believe it is preferable to
bzip2 for binary distributions.
Use if you wish.
I think those, with the updated 'sage-env' should allow some progress to be made
on Open Solaris.
Dave
Jaap Spies
> I've yet to get Sage to build on Open Solaris (x86/x64), though I have
> tried on a Sun Ultra 27 (Intel Xeon, not SPARC).
>
> I don't know the best configuration of the build tools, but have
> something seem as though they will allow progress to be made. In
> contrast Jaap seems to have some problems I've since solved.
>
> I've put binary copies of gcc, binutils and OpenSSL in
>
jaap@opensolaris:~/Downloads$ p7zip -d binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
7-Zip (A) 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05
p7zip Version 4.55 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Processing archive: binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
Extracting binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar
ERROR: E_FAIL
Total:
Folders: 0
Files: 0
Size: 0
Compressed: 140850011
bjc.so.2.0.0
-rwxr-xr-x root/root 1217 2010-01-06 22:34 gcc-4.3.4-GNU-assembler-Sun-linker/lib/amd64/libgij.la
-rwxr-xr-x root/root 110255080 2010-01-06 22:34 gcc-4.3.4-GNU-assembler-Sun-linker/lib/amd64/libgcj.so.9.0.0
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
I'm having som problems here.
Jaap
Dr. David Kirkby
> Dr. David Kirkby wrote:
>> I've yet to get Sage to build on Open Solaris (x86/x64), though I have
>> tried on a Sun Ultra 27 (Intel Xeon, not SPARC).
>>
>> I don't know the best configuration of the build tools, but have
>> something seem as though they will allow progress to be made. In
>> contrast Jaap seems to have some problems I've since solved.
>>
>> I've put binary copies of gcc, binutils and OpenSSL in
>>
>
> jaap@opensolaris:~/Downloads$ p7zip -d
> binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
>
> 7-Zip (A) 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05
> p7zip Version 4.55 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
>
> Processing archive:
> binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
>
> Extracting binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar
> ERROR: E_FAIL
Can you check the md5 checksums?
kirkby@boxen:~/Open_Solaris_Build_Tools$ openssl md5
binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
openssl-0.9.8l-binaries.tar.7z
MD5(binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z)=
f2d97f344aba52428f0a6c803e5bf4c4
MD5(openssl-0.9.8l-binaries.tar.7z)= 4db92648d937cca195f2382960b5dfe4
kirkby@boxen:~/Open_Solaris_Build_Tools$
I verified the files were ok before uploading them.
Dave
Dr. David Kirkby
> Can you check the md5 checksums?
>
> kirkby@boxen:~/Open_Solaris_Build_Tools$ openssl md5
> binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z
> openssl-0.9.8l-binaries.tar.7z
> MD5(binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z)=
> f2d97f344aba52428f0a6c803e5bf4c4
> MD5(openssl-0.9.8l-binaries.tar.7z)= 4db92648d937cca195f2382960b5dfe4
> kirkby@boxen:~/Open_Solaris_Build_Tools$
>
> I verified the files were ok before uploading them.
>
> Dave
What I mean is, after uploading the files, I computed the checksums on 'boxen'
and on my home machine, and verfied they were the same.
dave
Jaap Spies
MD5(binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar.7z)= f2d97f344aba52428f0a6c803e5bf4c4
MD5(openssl-0.9.8l-binaries.tar.7z)= 4db92648d937cca195f2382960b5dfe4
jaap@opensolaris:~/Downloads$
Looks ok to me!
Jaap
Jaap Spies
Are you sure?
Jaap
> dave
>
Dr. David Kirkby
Well, I can't understand this! It's crazy. I'd just decompressed it on boxen
without issue.
Log in there, copy it from my directory, and try it yourself! I'm going to
upload the '7za' binary from my sparc there too. I think I'll resist the
temptation to compress it into .lz format. p7zip is just a wrapper for 7za,
which has a lot more options.
I'm going to upload my 7za binary. Here its its checksum. Give it chance to
upload though, before trying grab it. I suggest you log onto boxen for this.
drkirkby@hawk:/tmp$ digest -a md5 7za.gz
891927989b0843fd680c75dd148bffba
Dr. David Kirkby
> Well, I can't understand this! It's crazy. I'd just decompressed it on
> boxen without issue.
>
> Log in there, copy it from my directory, and try it yourself! I'm going
> to upload the '7za' binary from my sparc there too. I think I'll resist
> the temptation to compress it into .lz format. p7zip is just a wrapper
> for 7za, which has a lot more options.
>
> I'm going to upload my 7za binary. Here its its checksum. Give it chance
> to upload though, before trying grab it. I suggest you log onto boxen
> for this.
>
> drkirkby@hawk:/tmp$ digest -a md5 7za.gz
> 891927989b0843fd680c75dd148bffba
>
OK, the 7za.gz binary is on boxen. It has the same checksum as on my machine.
(Don't try to run the binary on boxen, as its for a Solaris box, not an Linux one).
drkirkby@hawk:/tmp$ ldd /usr/bin/7za
libpthread.so.1 => /lib/libpthread.so.1
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libm.so.2 => /lib/libm.so.2
libthread.so.1 => /lib/libthread.so.1
libc.so.1 => /lib/libc.so.1
drkirkby@hawk:/tmp$ ls -l `ldd /usr/bin/7za | awk '{print $3}'`
-rwxr-xr-x 1 root bin 1704024 May 14 2009 /lib/libc.so.1
-rwxr-xr-x 1 root bin 345284 May 14 2009 /lib/libm.so.2
-rwxr-xr-x 1 root bin 17888 May 14 2009 /lib/libpthread.so.1
-rwxr-xr-x 1 root bin 20796 May 14 2009 /lib/libthread.so.1
-rwxr-xr-x 1 root bin 69640 May 14 2009 /usr/lib/libCrun.so.1
-rwxr-xr-x 1 root bin 1997352 May 14 2009 /usr/lib/libCstd.so.1
drkirkby@hawk:/tmp$ digest -a md5 `ldd /usr/bin/7za | awk '{print $3}'`
(/lib/libpthread.so.1) = 5309ff29f411801d15d44b9be78268aa
(/usr/lib/libCstd.so.1) = de9150e345826430bc7817d5dc5b24f0
(/usr/lib/libCrun.so.1) = 99ac85cc87bc1f05479afda7dced61f2
(/lib/libm.so.2) = 266cfb17360e0ac0724fc4beeda1ff89
(/lib/libthread.so.1) = 361c9abc5c24e803564274ba5e21e04a
(/lib/libc.so.1) = 087ca04f038efbc3191fb7cd1ea5d497
Jaap Spies
I'm sorry for the noise and the hassle. I found this morning (afternoon actually)
that I had a 'disk full', built one sage to much :(!
Installed your tools, but guess what:
In a fresh install of sage-4.3.1.alpha1 with the new sage-env I got
this stupid failure of python-2.6.2.p5 again.
Sleeping for three seconds before testing python
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/export/home/jaap/Downloads/sage-4.3.1.alpha1/local/lib/python/hashlib.py", line 136, in <module>
md5 = __get_builtin_constructor('md5')
File "/export/home/jaap/Downloads/sage-4.3.1.alpha1/local/lib/python/hashlib.py", line 63, in __get_builtin_constructor
import _md5
ImportError: No module named _md5
real 3m38.219s
user 1m57.112s
sys 0m48.044s
sage: An error occurred while installing python-2.6.2.p5
jaap@opensolaris:~/Downloads/sage-4.3.1.alpha1$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.3.4/configure --prefix=/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker --with-as=/usr/local/binutils-2.20/bin/as
--with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.3.4 (GCC)
jaap@opensolaris:~/Downloads/sage-4.3.1.alpha1$ ls /usr/local
bin i386-pc-solaris2.11 libexec ssl.old
binutils-2.20 include man
binutils-2.20-and-gcc-4.3.4-GNU-assembler-Sun-linker.tar info share
gcc-4.3.4-GNU-assembler-Sun-linker lib ssl
jaap@opensolaris:~/Downloads/sage-4.3.1.alpha1$
where the ssl is your binary.
Jaap
> Dave
>
Dr. David Kirkby
> I'm sorry for the noise and the hassle. I found this morning (afternoon
> actually)
> that I had a 'disk full', built one sage to much :(!
That explains why it failed. I would have expected some sort of error message -
usually one gets one at the console.
> Installed your tools, but guess what:
>
> In a fresh install of sage-4.3.1.alpha1 with the new sage-env I got
> this stupid failure of python-2.6.2.p5 again.
>
> Sleeping for three seconds before testing python
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File
> "/export/home/jaap/Downloads/sage-4.3.1.alpha1/local/lib/python/hashlib.py",
> line 136, in <module>
> md5 = __get_builtin_constructor('md5')
> File
> "/export/home/jaap/Downloads/sage-4.3.1.alpha1/local/lib/python/hashlib.py",
> line 63, in __get_builtin_constructor
> import _md5
> ImportError: No module named _md5
Em, that seems to be hitting you.
Have you tried building the ssl libraries and running the self-check. All my
tests passed. It could be you are using a broken compiler, so everything you
create is broke.
But if you use the ssl, gcc and binutils binaries I sent you, and make sure that
gcc is in your path first, I can't understand why the module is not building for
you.
> where the ssl is your binary.
The binaries I stuck on the web site install in /usr/local/ssl. I created a tar
file from the root directory, so actually if you to to / and extract the files
as root, it should install them in the right place. Just dont have another
directory called /usr/local/ssl, otherwise there will be a problem.
I think I need to update the Wiki with what I have found out about the Solaris
x86 build. But I'm puzzled why it builds for me, but not you. Have you use the
updated python package I posted, which makes use of the CFLAG64 variable?
Make sure to export
SAGE64=yes
Trying running this from your SAGE_ROOT
$ find . -exec file {} \; | grep 32
It will list any file with '32' in the name, but hopefully there wont be 100's
of them. I should show if you have any 32-bit objects around. If so, you need to
sort out how to get them to be 64-bit.
I did try creating a wrapper script called 'gcc', which had:
#!/bin/sh
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/bin/gcc -m64 $@
as its contents. That would hopefully force all binaries to be 64-bit, but not
everything in Sage will build like that. 'sqlite' complains about 'no end of
file' or similar.
As long as python is building 64-bit, which will need the updates I put on the
ticket, then the library should install. But if python is 32-bit, then it wont
link the 64-bit OpenSSL libraries, which is why hashlib (for md5) wont work.
Dave
Jaap Spies
> Jaap Spies wrote:
>
>
> Have you tried building the ssl libraries and running the self-check.
> All my tests passed. It could be you are using a broken compiler, so
> everything you create is broke.
>
I see no errors or failures after make test 2>&1 | tee test.log
> But if you use the ssl, gcc and binutils binaries I sent you, and make
> sure that gcc is in your path first, I can't understand why the module
> is not building for you.
>
>> where the ssl is your binary.
>
> The binaries I stuck on the web site install in /usr/local/ssl. I
> created a tar file from the root directory, so actually if you to to /
> and extract the files as root, it should install them in the right
> place. Just dont have another directory called /usr/local/ssl, otherwise
> there will be a problem.
>
I did exactly that.
> I think I need to update the Wiki with what I have found out about the
> Solaris x86 build. But I'm puzzled why it builds for me, but not you.
> Have you use the updated python package I posted, which makes use of the
> CFLAG64 variable?
>
See the p5 in my previous mail!
> Make sure to export
>
> SAGE64=yes
>
> Trying running this from your SAGE_ROOT
>
> $ find . -exec file {} \; | grep 32
>
> It will list any file with '32' in the name, but hopefully there wont be
> 100's of them. I should show if you have any 32-bit objects around. If
> so, you need to sort out how to get them to be 64-bit.
>
Nothing special I think:
jaap@opensolaris:~/Downloads/sage-4.3.1.alpha1$ find . -exec file {} \; | grep "ELF 32"
./local/bin/tachyon: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
./local/bin/size222: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
./local/bin/class.x: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
./local/bin/cws.x: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
./local/bin/f2c: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
./local/bin/sage_fortran.bin: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
./local/bin/dikcube: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
./local/bin/poly.x: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
./local/bin/nef.x: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
./local/lib/libgfortran.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped
> I did try creating a wrapper script called 'gcc', which had:
>
> #!/bin/sh
> /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/bin/gcc -m64 $@
>
just to have an extra -m64.
> as its contents. That would hopefully force all binaries to be 64-bit,
> but not everything in Sage will build like that. 'sqlite' complains
> about 'no end of file' or similar.
>
> As long as python is building 64-bit, which will need the updates I put
> on the ticket, then the library should install. But if python is 32-bit,
> then it wont link the 64-bit OpenSSL libraries, which is why hashlib
> (for md5) wont work.
>
Python-2.5.2.p5 builds in 64 bit mode. It surprises me it fails with exactly
your tools. Just flabbergasted.
I keep on trying.
Jaap
>
> Dave
>