I used to use LD_LIBRARY_PATH to choose CUDA toolkits, but then they
started shoving crap into /usr/bin because we have to break everything to
anything these days. But that's just my cold war engineer outlook from days
past.
On Wed, Mar 9, 2022 at 9:41 AM David A Case <david.case.rutgers.edu> wrote:
> 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
>
_______________________________________________
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
