[Numpy-discussion] [Nipy-devel] Impossibility to build nipy on recent numpy?
Thu Dec 10 16:40:28 CST 2009
On Thu, Dec 10, 2009 at 02:28:52PM -0800, Fernando Perez wrote:
> and that's because for each one of these, I correctly configure ALL of these:
> PATH: binary execution
> LD_LIBRARY_PATH: dynamic linker search path
> LIBRARY_PATH: static linking by gcc (like -L)
> CPATH: generic include path for gcc (like -I), used for all languages
> C_INCLUDE_PATH: C-specific include path, after CPATH
> CPLUS_INCLUDE_PATH: C++-specific include path, after CPATH
> PYTHONPATH: search path for python packages
I have an aversion to changing LD_LIBRARY_PATH, LIBRARY_PATH,
C_INCLUDE_PATH, CPATH, and CPLUS_INCLUDE_PATH, because I believe it leads
to non reproducibles builds or run-time.
More importantly, having to pull these tricks often reveals
non-compatible run-times, and thus impossibility to share code, eg to use
system code in localy-installed packages[*]. Now, we are indeed in such a
situation (because we have binary incompatibility between numpy 1.3 and
numpy 1.4), and there is nothing I can do to avoid it. It just makes me
I am confortable enough with a Linux build environment to pull tricks to
get stuff to build and run most of the time. I do however consider it
wrong to have to do so. I don't want to use these tricks systematicaly.
I'd much rather trip on the incompatibilities, and report them as bugs or
Thanks for offering, though.
[*] To give examples, I don't consider that I should have to build
atlas to use scipy svn. I do it quite often because I get better
performance, but it should not be necessary. Similarly, I want to be able
to install Mayavi svn and use the system VTK, and the system VTK Python
bindings. Matplotlib should be able to use pygtk from the system...
More information about the NumPy-Discussion