Preserve original LD_LIBRARY_PATH components.

[nascheme]

For the "python" tool, preserve the original components of LD_LIBRARY_PATH from the environment.

This caused me quite a lot of debugging time. If you install Python into a non-standard location and built it using --enable-shared, the Python executable will not be able to find Python shared libraries. One possible fix would be to set the rpath in the ELF files, like this:

patchelf --set-rpath "\$ORIGIN/../lib" /path-to-python/bin/python3.xy

Another idea that should work is to create a wrapper script, that sets LD_LIBRARY_PATH, e.g.

#!/bin/sh
prefix=/path-to-python
export LD_LIBRARY_PATH=$prefix/lib
exec $prefix/bin/python3

This fails with faber since it overrides the LD_LIBRARY_PATH environment variable. I think preserving the original components of it, like this patch does, is better. There should be little risk in doing so.

[stefanseefeld]

I agree, we do need a way of incorporating pre-defined environment variables. But instead of injecting them close to where the variables are used, I think it would be more robust to do this consistently wherever the equivalent faber features is defined, as there are many other similar situations, where users may want to merge variables such as CFLAGS, CXXFLAGS, etc., all of which map directly to faber tool-specific features.