[Numpy-discussion] Numscons issues: numpy.core.umath_tests not built, built-in ld detection, MAIN__ not being set-up

Peter Norton spacey-numpy-discussion@lenin....
Tue Dec 9 17:50:04 CST 2008


I've got a few issues that I hope won't be overwhelming on one message:

(1) Because of some issues in the past in building numpy with
numscons, the numpy.core.umath_tests don't get built with
numpy+numscons (at least not as of svn version 6128).

$ python -c 'import numpy; print numpy.__version__; import
numpy.core.umath_tests'
1.3.0.dev6139
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named umath_tests

What needs to be done to get this module incorporated into the numscons build?

(2) I've found that in numscons-0.9.4, the detection of the correct
linker assumes that if gcc is in use, the linker is gnu ld. However,
on solaris this isn't the recommended toolchain, so it's typical to
build gcc with gnu as and the solaris /usr/ccs/bin/ld under the hood.
What this means is that when setting a run_path in the binary (which
we need to do) the linker flags are set to "-Wl,-rpath=<library>".
However, this isn't valid for the solaris ld. It needs -R<libname>, or
-Wl,-R<libname>. I'm pretty sure that on Solaris trying to link a
library with -Wl,-rpath= and looking for an error should be enough to
determine the correct format for the linker.

(3) Numscons tries to check for the need for a MAIN__ function when
linking with gfortran. However, any libraries built with numscons come
out with an unsatisfied dependency on MAIN__. The log looks like this
in build/scons/numpy/linalg/config.log looks like this:

scons: Configure: Checking if gfortran needs dummy main -
scons: Configure: "build/scons/numpy/linalg/sconf/conftest_0.c" is up to date.
scons: Configure: The original builder output was:
  |build/scons/numpy/linalg/sconf/conftest_0.c <-
  |  |
  |  |int dummy() { return 0; }
  |  |
  |
scons: Configure: "build/scons/numpy/linalg/sconf/conftest_0.o" is up to date.
scons: Configure: The original builder output was:
  |gcc -o build/scons/numpy/linalg/sconf/conftest_0.o -c -O3 -m64 -g
-fPIC -DPIC build/scons/numpy/linalg/sconf/conftest_0.c
  |
scons: Configure: Building "build/scons/numpy/linalg/sconf/conftest_0"
failed in a previous run and all its sources are up to date.
scons: Configure: The original builder output was:
  |gfortran -o build/scons/numpy/linalg/sconf/conftest_0 -O3 -g
-L/usr/local/lib/gcc-4.3.1/amd64 -Wl,-R/usr/local/lib/gcc-4.3.1/amd64
-L/usr/local/amd64/python/lib -Wl,-R/usr/local/amd64/python/lib -L.
-lgcc_s build/scons/numpy/linalg/sconf/conftest_0.o
  |

It then goes on to discover that it needs main:

scons: Configure: "build/scons/numpy/linalg/sconf/conftest_1" is up to date.
scons: Configure: The original builder output was:
  |gfortran -o build/scons/numpy/linalg/sconf/conftest_1 -O3 -g
-L/usr/local/lib/gcc-4.3.1/amd64 -Wl,-R/usr/local/lib/gcc-4.3.1/amd64
-L/usr/local/amd64/python/lib -Wl,-R/usr/local/amd64/python/lib -L.
-lgcc_s build/scons/numpy/linalg/sconf/conftest_1.o
  |
scons: Configure: (cached) MAIN__.


Doesn't this clearly indicate that a dummy main is needed?  I'm
working around this with a silly library that just has the MAIN__
symbol in it, but I'd love to do without that.

Thanks,

Peter


More information about the Numpy-discussion mailing list