Jaap Spies wrote:
Jaap Spies wrote:
Dr. David Kirkby wrote:
I get the following problem when trying to make a 64-bit build of Sage
on Open Solaris (Intel Xeon processor). I would add the build of ATLAS
failed, so I had to just skip that.
[...]
The problem is probably a 32 vs 64 bit issue. See the spkg-install:
CFLAGS and friends are not correctly used:
# numpy's distutils is buggy and runs a conftest without
# taking CFLAGS into account. With 64 bit OSX this results
I patched the spkg-install file using the gcc_fake trick generally
when SAGE64="yes"
It might be, though I am not 100% sure.
I tried creating a small script called gcc, which was in the patch befor the
compiler. That script just added -m64, then called the real gcc. Unfortunately,
whilst that worked and permitted most things to build in 64-bit mode,
irrespective of the contents of spkg-install, not all parts of Sage will build
with a wrapper like that. There's messages like "not ending in a new line". So
its not so easy to trick Sage into building a gcc with -m64. That's why I'm keen
for the new sage-env to get in. Then we can create 64-bit packages with far less
hassle.
assuming /usr/bin/gcc is used:
sage subshell$ cat gcc_fake
#!/bin/bash
/usr/bin/gcc -m64 $@
building now failed because of my flawed python :(
We need to solve this and it certainly can be solved.
As I said to you before, gcc can be configured to use either Sun or GNU
assemblers, and Sun or GNU linkers. Given ATLAS appears to have some assembly
code only the GNU assembler can understand, it looks to me that we should use
the GNU assembler and the Sun linker. I'm *reasonably* confident this is the
best combination, but by no means certain.
Some people I trust, tell me that gcc 4.3.4 is probably the most stable gcc. So
my build system, which is now working reasonably well, is built like this:
drkir...@hawk:~/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)
Note I tend to put tools like 'binutils' in their own directory (not simply
/usr/local) and also the compiler in it's own directory. That means they things
are reasonably isolated. (gmp and mpfr are however in /usr/local).
Try that, build OpenSSL like that, and then revisit Sage. Make sure you set
CFLAGS to to include -m64, then try the python attached to
http://trac.sagemath.org/sage_trac/ticket/7761
So until sage-env gets update, you will need to do something like
$ export SAGE64=yes
$ export CLFAGS=-m64
$ export CXXFLAGS=-m64
$ export CFLAG64=-m64
$ export CXXFLAGS=-m64
Hopefully, that should fix it for you. Once you have python working, we can
investigate further.
import _md5
ImportError: No module named _md5
Error building numpy.
/export/home/jaap/Downloads/sage-4.3.1.alpha0.old
sage subshell$
Jaap
It's critical you get this solved. The modified ticket should allow python to
build in 64-bit mode, using the 64-bit OpenSSL libraries.
Dave
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
