Dr. David Kirkby wrote:
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:
j...@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
--
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