I just noticed that "all" of my automagically generated Lmod modulefiles set LD_LIBRARY_PATH to prefix().lib.
This surprised me. The section of the spack docs on transitive-dependencies extol the virtues of the RPATH approach and it's one of the things that attracts me to Spack.
Of the three problematic cases that section discusses, it seems that only 2) & 3) require providing a LD_LIBRARY_PATH (and arguably that's a bug) and I'd expect that to be rare.
I know that I can add LD_LIBRARY_PATH to the environment_blacklist in the modules.yaml file, but I wonder how many surprises are lurking down that road.
Would it be better to not automagically set LD_LIBRARY_PATH and force packages that require it (e.g. Python extensions) to explicitly provide it?
FWIW, I ran into this when I was trying to understand why UGE was telling me that it was stripping LD_LIBRARY_PATH from my qsub -V-ed job but that it appeared to be set anyway....
I just noticed that "all" of my automagically generated Lmod modulefiles set LD_LIBRARY_PATH to
prefix().lib.This surprised me. The section of the spack docs on transitive-dependencies extol the virtues of the RPATH approach and it's one of the things that attracts me to Spack.
Of the three problematic cases that section discusses, it seems that only 2) & 3) require providing a
LD_LIBRARY_PATH(and arguably that's a bug) and I'd expect that to be rare.I know that I can add
LD_LIBRARY_PATHto theenvironment_blacklistin themodules.yamlfile, but I wonder how many surprises are lurking down that road.Would it be better to not automagically set
LD_LIBRARY_PATHand force packages that require it (e.g. Python extensions) to explicitly provide it?FWIW, I ran into this when I was trying to understand why UGE was telling me that it was stripping LD_LIBRARY_PATH from my
qsub -V-ed job but that it appeared to be set anyway....