LD_LIBRARY_PATH -vs- SHLIB_PATH

[Dan Ryan_4]

I recently had an issue on one of our HP-UX 11.0 servers, after upgrading EMC's Navisphere product. Navisphere runs a daemon ,naviagent, and provides a cli, navicli. After the upgrade some commands issued via the cli would cause the daemon to quit. The vendor provided work around was to remove /usr/lib and /opt/Navisphere/lib from SHLIB_PATH replacing them with /usr/lib/pa1.1 . Which appears to work. Setting SHLIB_PATH to null also works.

What I'm wondering about is given the chatr and tusc output below , why is this working?

It looks to me like /usr/lib is being used by the executables even though the SHLIB_PATH and LD_LIBRARY_PATH are being set to avoid this.

Funnier still is if /usr/lib is in the SHLIB_PATH variable I can recreate the failure.

Are the naviagent and navicli using /usr/lib as specified in the shared library list?
Are they actually using the library in the LD_LIBRARY_PATH variable?
If LD_LIBRARY_PATH and SHLIB_PATH are set which one in used?

Thanks in advance for you input. I just don't feel comfortable with the "fix" even though it looks to be working.

chatr `which naviagent`
/opt/Navisphere/bin/naviagent:
shared executable
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /usr/lib/libdld.1
dynamic /usr/lib/libstd.1
dynamic /usr/lib/libstream.1
dynamic /usr/lib/libCsup.1
dynamic /usr/lib/pa1.1/libcl.1
dynamic /usr/lib/libc.1
shared library binding:
deferred
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
third quadrant global data space disabled
data page size: D (default)
instruction page size: D (default)
nulptr references disabled
shared library private mapping disabled
shared library text merging disabled

chatr `which navicli`
/opt/Navisphere/bin/navicli:
shared executable
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /usr/lib/libdld.1
dynamic /usr/lib/libstd.1
dynamic /usr/lib/libstream.1
dynamic /usr/lib/libCsup.1
dynamic /usr/lib/pa1.1/libcl.1
dynamic /usr/lib/libc.1
shared library binding:
deferred
global hash table disabled


echo $SHLIB_PATH
echo $LD_LIBRARAY_PATH
sh: LD_LIBRARAY_PATH: Parameter not set.

sapap9# /usr/contrib/bin/tusc navicli lunmapinfo | egrep -i 'libdld.1|libstd.1|libstream.1|libCsup.1|libcl.1'
open("/usr/lib/libdld.1", O_RDONLY, 057) ......................................................... = 3
open("/usr/lib/pa1.1/libcl.1", O_RDONLY, 057) .................................................... = 3
open("/usr/lib/libdld.1", O_RDONLY, 057) ......................................................... = 3
open("/usr/lib/libCsup.1", O_RDONLY, 057) ........................................................ = 3
open("/usr/lib/libstream.1", O_RDONLY, 057) ...................................................... = 3
open("/usr/lib/libstd.1", O_RDONLY, 057) ......................................................... = 3
open("/usr/lib/libdld.1", O_RDONLY, 057) ......................................................... = 3

[Heironimus]

I can't tell you why it does and doesn't work, but I can answer a couple questions. If I had to guess I'd say your problem has something to do with different versions of the same library in different locations.

/usr/lib is always checked, SHLIB_PATH just adds other directories ahead of it. The only time you'd want to put /usr/lib in SHLIB_PATH is when you need libraries from other directories but still want to make sure you use the system-wide standard libraries instead of any equivalents in the other locations.

As I recall, on HP-UX SHLIB_PATH is used for 32-bit and LD_LIBRARY_PATH is used for 64-bit. They do the same thing, but for different types of binary.

You might be able to find out exactly what's wrong by running ldd on the binary and comparing the output with different SHLIB_PATH settings.

[Dan Ryan_4]

Thanks for the ldd command.
Looks like LD_LIBRARY_PATH is ignored.
An empty SHLIB_PATH results in all modules loading from /usr/lib and naviagent doesn't crash. Having /usr/lib explicitly in the SHLIB_PATH all modules are loaded from /usr/lib but the naviagent will crash.
Go figure.

[Dennis Handly]

I can't see why there is any difference. The only file I see in pa1.1 is libcl.1 and that is a symlink to /usr/lib/.

The only strange thing is these applications were made for 10.20.

The application doesn't try to dynamically load any other lib with shl_load??

[Volker Borowski]

Hi,

LD_LIBRARY_PATH is used on Solaris.

Check out
http://docs.hp.com/en/B2355-90654/ch04s03.html#d0e8541
at the very bottom.

Looks like /usr/lib/pa1.1/libcl.1
is exactly the guy in charge.

When you put /usr/lib in SHLIB_PATH, the wrong /usr/lib/libcl.1 is used instead.

If
/usr/lib/pa1.1/libcl.1
is symlinked to the
/usr/lib/libcl.1
on your box, I do not understand the error :-(

Volker

[dirk dierickx]

it depends, read the manpake for 'dld.sl' to get more info on when, what is used and how.