On Wed, Dec 10, 2008 at 12:59 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Peter Norton wrote: >> 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? > > you should not need this module, it is not built using the normal build > of numpy either. Did you do a clean build (rm -rf build and removing the > install directory first) ? It was enabled before but is commented out ATM.
Our users would like to have this module for testing purposes I believe. It should be enabled. - Hide quoted text - >> (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. > > Scons and hence numscons indeed assume that the linker is the same as > the compiler by default. It would be possible to avoid this by detecting > the linker at runtime, to bypass scons tools choice, like I do for C, > C++ and Fortran compilers. The whole scons tools sub-system is > unfortunately very limited ATM, so there is a lot of manual work to do > (that's actually what most of the code in numscons/core is for). > >> (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: > > It may be linked to the sun linker problem above. Actually, the dummy > main detection is not used at all for the building - it is necessary to > detect name mangling used by the fortran compiler, but that's it. I > assumed that a dummy main was never needed for shared libraries, but > that assumption may well be ill founded. > > I never had problems related to this on open solaris, with both native > and gcc toolchains, so I am willing to investiage first whether it is > linked to the sun linker problem or not. > > Unfortunately, I won't have the time to work on this in the next few > months because of my PhD thesis; the sun linker problem can be fixed by > following a strategy similar to compilers, in > numscons/core/initialization.py. You first need to add a detection > scheme for the linker in compiler_detection.py. Thanks, I'll look into this. It is true that working with opensolaris is a lot easier. Sun should have done it years ago. Thanks again, -Peter _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
