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

Reply via email to