Back in the beginning of the summer, I jumped through a lot of hoops to build numpy+scipy on solaris, 64-bit with gcc. I received a lot of help from David C., and ended up, by some very ugly hacking, building an acceptable numpy+scipy+matplotlib trio for use at my company. However, I'm back at it again trying to build the same tools in both a 32-bit abi and a 64-bit ABI. I'm starting with the 32-bit build, because I suspect it'd be simpler (less trouble adding things like -m64 and other such flags). However, I've run into a very basic problem right at the get-go. This time instead of bothering David at the beginning of my build, I was hoping that other people may have experience to contribute to resolving my issues. Here is my build environment: 1) gcc-4.3.1 2) Solaris 10 update 3 3) sunperf libraries (for blas+lapack support) I can provide more detail since that's not a very specific list. Anyway, when I try building numpy-1.2.1 after setting up my site.cfg and build-related environment this is what I get: Setting the site.cfg Running from numpy source directory. F2PY Version 2_5972 non-existing path in 'numpy/core': 'code_generators/array_api_order.txt' [continues...] scons: Reading SConscript files ... scons: warning: Ignoring missing SConscript 'build/scons/numpy/core/SConscript' File "/usr/local/python-2.5.1/lib/python2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py", line 108, in DistutilsSConscript scons: done reading SConscript files. scons: Building targets ... scons: *** [Errno 2] No such file or directory: 'numpy/core/../../build/scons/numpy/core/sconsign.dblite' scons: building terminated because of errors. error: Error while executing scons command. See above for more information. If you think it is a problem in numscons, you can also try executing the scons command with --log-level option for more detailed output of what numscons is doing, for example --log-level=0; the lowest the level is, the more detailed the output it. [etc.] then similar errors repeat themselves over and over including ignoreing missing SConscript, and no sconsign.dblite file, until the build bombs out. I've got numscons installed from pypi:
import numscons.version numscons.version.VERSION '0.9.4'
Can anyone get me on the right track here? Thanks, -Peter
On Tue, Nov 25, 2008 at 4:54 PM, Peter Norton < spacey-numpy-discussion@lenin.net> wrote:
Back in the beginning of the summer, I jumped through a lot of hoops to build numpy+scipy on solaris, 64-bit with gcc. I received a lot of help from David C., and ended up, by some very ugly hacking, building an acceptable numpy+scipy+matplotlib trio for use at my company.
However, I'm back at it again trying to build the same tools in both a 32-bit abi and a 64-bit ABI. I'm starting with the 32-bit build, because I suspect it'd be simpler (less trouble adding things like -m64 and other such flags). However, I've run into a very basic problem right at the get-go. This time instead of bothering David at the beginning of my build, I was hoping that other people may have experience to contribute to resolving my issues.
Here is my build environment:
1) gcc-4.3.1 2) Solaris 10 update 3 3) sunperf libraries (for blas+lapack support)
I can provide more detail since that's not a very specific list.
Anyway, when I try building numpy-1.2.1 after setting up my site.cfg and build-related environment this is what I get:
Setting the site.cfg Running from numpy source directory. F2PY Version 2_5972 non-existing path in 'numpy/core': 'code_generators/array_api_order.txt' [continues...] scons: Reading SConscript files ...
scons: warning: Ignoring missing SConscript 'build/scons/numpy/core/SConscript' File "/usr/local/python-2.5.1/lib/python2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py", line 108, in DistutilsSConscript scons: done reading SConscript files. scons: Building targets ... scons: *** [Errno 2] No such file or directory: 'numpy/core/../../build/scons/numpy/core/sconsign.dblite' scons: building terminated because of errors. error: Error while executing scons command. See above for more information. If you think it is a problem in numscons, you can also try executing the scons command with --log-level option for more detailed output of what numscons is doing, for example --log-level=0; the lowest the level is, the more detailed the output it. [etc.]
then similar errors repeat themselves over and over including ignoreing missing SConscript, and no sconsign.dblite file, until the build bombs out.
I've got numscons installed from pypi:
import numscons.version numscons.version.VERSION '0.9.4'
Can anyone get me on the right track here?
What happens if you go the usual python setup.py {build,install} route? Chuck
On Wed, Nov 26, 2008 at 8:54 AM, Peter Norton
scons: warning: Ignoring missing SConscript 'build/scons/numpy/core/SConscript' File "/usr/local/python-2.5.1/lib/python2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py", line 108, in DistutilsSConscript scons: done reading SConscript files. scons: Building targets ... scons: *** [Errno 2] No such file or directory:
It could be considered a bug because the error message is bad: the problem really is the missing scons script (it is not so easy to handle because scons is in a different process than distutils, so it is difficult to get useful information back from the scons process). Which version of numpy are you using ? David
On Tue, Nov 25, 2008 at 11:28 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Charles R Harris wrote:
What happens if you go the usual python setup.py {build,install} route?
Won't go far since it does not handle sunperf.
David
Even though the regular build process appears to complete, it seems to be doing the wrong thing. It seems, for instance, that lapack_lite.so is being built as an executable: nortonp@is6 11:14 ~ $ gnu file /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped ??? -Peter
On Thu, Nov 27, 2008 at 1:16 AM, Peter Norton
On Tue, Nov 25, 2008 at 11:28 PM, David Cournapeau
wrote: Charles R Harris wrote:
What happens if you go the usual python setup.py {build,install} route?
Won't go far since it does not handle sunperf.
David
Even though the regular build process appears to complete, it seems to be doing the wrong thing. It seems, for instance, that lapack_lite.so is being built as an executable:
nortonp@is6 11:14 ~ $ gnu file /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped ???
I think this is "expected" if python was built with one compiler and numpy with another (python with Forte and numpy with gcc). Distutils knows the options from python itself, wether it is optional in numscons (in theory, you can set it up to use python options or known configurations). I don't think you will have much hope with distutils, unless you are ready to add code by yourself (sunperf will be very difficult to support, though). The numscons error has nothing to do with solaris, the scons scripts should be there. Could you give me the full output of python setupscons.py scons ? David
David Cournapeau wrote:
On Thu, Nov 27, 2008 at 1:16 AM, Peter Norton
wrote: On Tue, Nov 25, 2008 at 11:28 PM, David Cournapeau
wrote: Charles R Harris wrote:
What happens if you go the usual python setup.py {build,install} route?
Won't go far since it does not handle sunperf.
David
Even though the regular build process appears to complete, it seems to be doing the wrong thing. It seems, for instance, that lapack_lite.so is being built as an executable:
nortonp@is6 11:14 ~ $ gnu file /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so /usr/local/python-2.5.1/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped ???
Hi,
I think this is "expected" if python was built with one compiler and numpy with another (python with Forte and numpy with gcc). Distutils knows the options from python itself, wether it is optional in numscons (in theory, you can set it up to use python options or known configurations).
Hmm, I have recently build numpy 1.2.1 on FreeBSD 7 and had trouble with lapacK_lite.so. The fix was to add a "-shared" flag. I needed the same fix for Cygwin.
I don't think you will have much hope with distutils, unless you are ready to add code by yourself (sunperf will be very difficult to support, though).
Why? What do you think makes sunperf problematic? [Not that I want to do the work, just curious :)]
The numscons error has nothing to do with solaris, the scons scripts should be there. Could you give me the full output of python setupscons.py scons ?
David
Cheers, Michael
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Nov 27, 2008 at 1:38 PM, Michael Abshoff
Why? What do you think makes sunperf problematic? [Not that I want to do the work, just curious :)]
I *know* it will be difficult :) The problem of sunperf is that you cannot just link a few libraries to make it work, you need to use compiler specific options like -xlic_lib=sunperf + some compiler options like align and co. Worse, at least of the versions I tried, the option does not work for shared libraries (when using the -G option). So using it with gcc is complicated. The only reason why it works in numscons is because there is a workaround ala autoconf which links sunperf to a dummy main, and I added a small linker parser which parse the output of verbose link step to get the options dynamically: http://bazaar.launchpad.net/%7Edavid-ar/numpy.scons.support/0.9/annotate/314... In theory, it could be added with distutils. Not that I will do it myself either, though. David
participants (5)
-
Charles R Harris
-
David Cournapeau
-
David Cournapeau
-
Michael Abshoff
-
Peter Norton