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.
...more later...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 09 2022 - 14:00:02 PST
