conda/conda-build — pull request #228 by bjodah (2014-10-19 09:48:09+00:00)
Title: Set LIBRARY_PATH and INCLUDE_PATH on unix.

Hi all!

First off: huge thanks for conda - I think it's great and definitely the way forward for the python eco system.

I have been trying to migrate my own "stack" to use conda, in doing so I've run into a bug (or at least a not too well documented behaviour IMHO). I set up a "python best practices demo" for my own reference (and minimal example to debug the error I ran into). Here is my failing travis build:
https://travis-ci.org/bjodah/pybestprac/builds/38401129

My Python 3 build started failing since the linker couldn't find python3.4m.so, even though it is present in the ENV_ROOT/lib. Manually adding it to LIBRARY_PATH had no effect, which led me into digging into the ``conda-build`` package where I found that you use a custom environment (which I guess is needed for reproducibility).

At first I thought it was a Travis related issue or my own package calling the compiler but I have narrowed it down to ``conda build`` by doing this on my own machine:

$ LIBRARY_PATH=~/miniconda/envs/_build/lib conda build conda-recipe
/.../
pycompilation.util.CompilationError: Error executing '/usr/bin/g++ -pthread -shared -std=c++0x -fopenmp -o /home/bjorn/miniconda/conda-bld/work/build/temp.linux-i686-3.4/_euclid.so src/euclid_enorm.o src/euclid.o pybestprac/_euclid.o -lpython3.4m -lgfortranbegin -lgfortran' in build/temp.linux-i686-3.4. Command exited with status 1 after givning the following output: /usr/bin/ld: cannot find -lpython3.4m
collect2: error: ld returned 1 exit status
$ cd /home/bjorn/miniconda/conda-bld/work/build/temp.linux-i686-3.4
$ LIBRARY_PATH=~/miniconda/envs/_build/lib /usr/bin/g++ -pthread -shared -std=c++0x -fopenmp -o /home/bjorn/miniconda/conda-bld/work/build/temp.linux-i686-3.4/_euclid.so src/euclid_enorm.o src/euclid.o pybestprac/_euclid.o -lpython3.4m -lgfortranbegin -lgfortran

and the last command completes successfully.

Therefore, I think it would be good to set:

- ``LIBRARY_PATH`` used by most *nix systems to find libraries during linking
- ``INCLUDE_PATH`` used by most *nix systems to find headers during compilation

where only LIBRARY_PATH would be needed to remedy my problem at hand. I think most people who might have run into thuis have used the work around to "apt-get install python3-dev", but then the linking is against the system specific shared object, not against the conda environment one.