Hi,
Executive summary - i don't think this is an issue.
rpath definitely should (and does on clusters i have built on, all rhels)
have precedence over everything else including LD_LIBRARY_PATH.
See the ld man page (again on rhels)
===
The linker uses the following search paths to locate required shared libraries:
1. Any directories specified by -rpath-link options.
2. Any directories specified by -rpath options. The difference between -rpath and
-rpath-link is that directories specified by -rpath options are included in the
executable and used at runtime, whereas the -rpath-link option is only effective at
link time. Searching -rpath in this way is only supported by native linkers and
cross linkers which have been configured with the --with-sysroot option.
3. On an ELF system, for native linkers, if the -rpath and -rpath-link options were not
used, search the contents of the environment variable "LD_RUN_PATH".
4. On SunOS, if the -rpath option was not used, search any directories specified using
-L options.
5. For a native linker, search the contents of the environment variable
"LD_LIBRARY_PATH".
...
7. The default directories, normally /lib and /usr/lib.
... thru 8.
===
At OSC we have long used -rpath manually in our public installs and have
not had conflicts with LD_LIBRARY_PATH as far as i know. I think this
~automatic behavior is one of the (few :) advantages of cmake.
However, cmake is not setting up rpath for everything.
I just used ldd on sander built with the cmake mechanism while changing
compiler modules and thus LD_LIBRARY_PATH; i do see the behavior that
you report for libstdc++.so.6, libgfortran.so.5, libgcc_s.so.1, and
libquadmath.so.0. If i unload all compiler modules then:
/amber20/bin/sander: error while loading shared libraries: libgfortran.so.5: cannot open shared object file: No such file or directory
But these are not Amber built libraries and there's nothing to do for
these types of issues other than to document the dependencies of our binaries.
scott
On Wed, Mar 09, 2022 at 09:50:10AM -0800, Scott Le Grand wrote:
> 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.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 09 2022 - 11:30:02 PST
