I need some experienced advice here, about LD_LIBRARY_PATH.
The cmake build procedure (seems to) correctly add .rpath info into
executables, so that LD_LIBRARY_PATH is not needed.
However, if a user's environment has LD_LIBRARY_PATH set, those directories
are searched first. [At least, this is what "ldd" reports: it says the
exectuable is linked to a folder from LD_LIBRARY_PATH, even if that location
is from some other Amber installation; if I unset LD_LIBRARY_PATH, then
ldd reports the correct library locations.] This creates a problem when
some other Amber installation has set LD_LIBRARY_PATH via its amber.sh script.
For example, developers are soon going to be building and testing release
candidates. They will almost certainly have an existing LD_LIBRARY_PATH
that points to some existing installation. So: what's the best way to
handle things like that? Ask users to remove other amber entries from their
environment? Force users to add an entry to the release candidate library,
even though it's not really needed? Do something else?
Also, our existing amber.sh script say this:
# Note that LD_LIBRARY_PATH is only necessary to help Amber's Python programs find their dynamic libraries,
# unless Amber has been moved from where it was installed.
About the first part (only necessary for Python): why isn't setting the
PYTHONPATH variable, which amber.sh also does, good enough?
About the second part: could we maybe have special instructions for the
(rare) users who want/need to move their installations to a new location?
Basically, should we consider *not* setting LD_LIBRARY_PATH via amber.sh in
the future?
If I have garbled or misrepresented things, corrections would be most
welcome. As, of course, are suggestions about the best ways to handle this
issue for the upcoming release.
...thx...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 09 2022 - 10:00:03 PST
