On Wed, Mar 09, 2022 at 04:42:54PM -0500, David A Case wrote:
> On Wed, Mar 09, 2022, Scott Brozell wrote:
> >
> >rpath definitely should (and does on clusters i have built on, all rhels)
> >have precedence over everything else including LD_LIBRARY_PATH.
>
> OK...I'm probably mistaken then about how ldd finds shared libraries when
> LD_LIBRARY_PATH is empty. It may not have anything to do with rpath.
>
> Here's what I see on Ubuntu:
>
> pop-os% echo $LD_LIBRARY_PATH
> /home/case/msander/lib:/home/case/amber20/lib:/opt/intel/oneapi/mkl/latest/lib/intel64
>
> Here the /home/case/amber20/lib entry is from my "main" Amber installation.
>
> If I look at a test build in /home/case/dist/amber22/bin:
>
> pop-os% ldd pmemd
> libemil.so => /home/case/amber20/lib/libemil.so (0x00001496d03a2000)
> libnetcdff.so.6 => /home/case/amber20/lib/libnetcdff.so.6 (0x00001496d032c000)
>
> It's picking up libraries that we don't want, from an unrelated build of the
> amber codes.
>
> pop-os% export LD_LIBRARY_PATH= # to wipe out my environmnt variable
>
> pop-os% ldd pmemd libemil.so => /home/case/dist/amber22//lib/libemil.so
> (0x00001525a1974000)
> libnetcdff.so.6 => /home/case/dist/amber22//lib/libnetcdff.so.6 (0x00001525a18de000)
>
> How is is looking in the lib file created by the test installation, i.e.
> in /home/case/dist/amber22//lib.
>
> Most of the time, I don't care, since the emil and netcdf libraries rarely
> change, but that might not always be the case. In any event, we clearly want
> tests of release candidates to be using the proper libraries, and not other
> locations that might show up in a LD_LIBRARY_PATH variable.
>
> The obvious caveat here is that I know little about rpath, rpath-link,
> differences between ld and ldd, etc. etc. I don't evn know that what ldd
> reports is what running the program itself would actually use.
I do not see the behavior that you do; /tmp/amber20 is a recent amber
installed by cmake with gnu from a current git tree:
ldd /tmp/amber20/bin/pmemd|g emil
3: libemil.so => /tmp/amber20//lib/libemil.so (0x00002b563f34a000)
Then i load amber/18 which changes LD_LIBRARY_PATH a lot, eg
LD_LIBRARY_PATH=/usr/local/amber/intel/19.0/mvapich2/2.3/18/lib: ...
ldd /tmp/amber20/bin/pmemd | g emil
3: libemil.so => /tmp/amber20//lib/libemil.so (0x00002b09cd4b8000)
What is your output from this:
readelf -a /tmp/amber20/bin/pmemd | g path
148: 0x000000000000000f (RPATH) Library rpath: [/tmp/amber20//lib]
346: 15: 00000000009331a0 256 OBJECT GLOBAL DEFAULT 26 __nfe_colvar_mod_MOD_path
661: 330: 00000000009332a0 0x27100 OBJECT GLOBAL DEFAULT 26 __nfe_colvar_mod_MOD_path
3540: 1117: 00000000009331a0 256 OBJECT GLOBAL DEFAULT 26 __nfe_colvar_mod_MOD_path
3855: 1432: 00000000009332a0 0x27100 OBJECT GLOBAL DEFAULT 26 __nfe_colvar_mod_MOD_path
Does your man ld show the same search path priorities ?
Maybe this has something to do with runpath (suggested by web searching)
which shows up way down in the list for me:
the ld man page (again on rhels)
===
The linker uses the following search paths to locate required shared libraries:
...
6. For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared
library are searched for shared libraries needed by it. The "DT_RPATH" entries are
ignored if "DT_RUNPATH" entries exist.
===
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 09 2022 - 18:30:02 PST
