Folks,
-L/path/to/lib -lfoo will look for the foo library (libfoo.so or
libfoo.a on Linux) in the /path/to/lib directory.
In the case of a dynamic library (e.g. libfoo.so), its dependencies will
*not* be searched in /path/to/lib
(and this is where LD_LIBRARY_PATH helps)
that can be evidenced with a quite simple test (libfoo.so depends on
libbar.so, both in the current directory)
/* I run on an up-to-date CentOS 7 box, other linkers such as the ubuntu
one might have a different behavior */
$ LD_LIBRARY_PATH=. ldd libfoo.so
linux-vdso.so.1 => (0x00007ffde9a3e000)
libbar.so => ./libbar.so (0x00007f793f5c9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f793f1fb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f793f9cd000)
$ gcc -o test test.c -L. -lfoo
/usr/bin/ld: warning: libbar.so, needed by ./libfoo.so, not found (try
using -rpath or -rpath-link)
./libfoo.so: undefined reference to `bar'
collect2: error: ld returned 1 exit status
fails without LD_LIBRARY_PATH, but
$ LD_LIBRARY_PATH=. gcc -o test test.c -L. -lfoo
works.
FWIW, no LD_LIBRARY_PATH is needed at link time if the binary is *also*
linked with libbar.so
(and this is *not* what is reported by config.log)
$ gcc -o test2 test2.c -L. -lfoo -lbar
Chris,
with LD_LIBRARY_PATH, are you facing the exact same error
(e.g. libsharp_coll.so.2 so cannot be found) ?
or are you only having an issue with undefined references in
/lib64/libibnetdisc.so.5 ?
Cheers,
Gilles
On 10/16/2019 1:42 AM, Peter Kjellström via devel wrote:
On Tue, 15 Oct 2019 15:40:24 +0000
"Jeff Squyres \(jsquyres\) via devel" <devel@lists.open-mpi.org> wrote:
...
1) do you expect this to just work even if the linker has no idea
where to find libsharp.so ?
No, of course not. :-) That's what the additional -L was for.
LIBRARY_PATH is the corresponding variable for -L if one wants one.
This should work for both static and dynamic libraries as -L.
LD_LIBRARY_PATH on the other hand is run time for dynamic libraries
(configures the logic used by ld.so).
In a similar manner CPATH is an option to -I.
/Peter K
