Any way to change linking to avoid the LD_PRELOAD on HPUX?

Question

I think I understand why I need LD_PRELOAD set when loading a multithreaded applicatoin that loads a single threaded library that loads libcl.2 but I was wondering if I could use some linker setting to avoid this. Any help appreciated.

Update:

Perl loads dynamic /usr/lib/libc.2 Perl loads DB2.sl DB2 Attempts to load dynamic /usr/lib/libcl.2

Could it be the fact that something with that shared object name is already loaded it then fails.

/usr/lib>pwd

/usr/lib

/usr/lib>ls -lt | grep libcl.2

-r-xr-xr-x 1 bin bin 1261568 Feb 14 2003 libcl.2

lrwxr-xr-x 1 root sys 9 Nov 21 2002 libcl.sl -> ./libcl.2

Now the reason refuses to go looking for something of this same name might be explained by the chattr output:

Both have the disable fields set so they won't look in the environment nor use the alternate name

chatr on perl perl:

     shared executable
     shared library dynamic path search:
         SHLIB_PATH     disabled  second
         embedded path  disabled  first  Not Defined
     shared library list:
         dynamic   /usr/lib/libnsl.1
         dynamic   /usr/lib/libnm.sl
         dynamic   /usr/lib/libdld.2
         dynamic   /usr/lib/libm.2
         dynamic   /usr/lib/libsec.2
         dynamic   /usr/lib/libpthread.1
         dynamic   /usr/lib/libc.2

chatr on DB2.sl DB2.sl:

     shared library
     shared library dynamic path search:
         SHLIB_PATH     disabled  second
         embedded path  disabled  first  Not Defined
     shared library list:
         dynamic   /opt/IBM/db2/V8.1/lib/libdb2.sl
         dynamic   /usr/lib/libcl.2

Could maybe the chatr settings of one of the libraries be adjusted?

Update: why not just make them use the same name for the library.

Answer 1

Depending on your compiler/linker (thinking of the HPUX machines I logged onto more than a decade ago makes me shudder), --rpath might help: from what I understand, in your case the rtld is looking in the wrong place first, so that's why you want to preload some other version of the lib, right? In that case, rpath will embed an additional search location into the compiled binary, which you can use to point it to the directory where your preferred version is coming from.

Hope this helps. -V

Answer 2

I wrote an article about shared libraries on HP-UX and tried to make it clear and comprehensive. I found myself having to debug why programs couldn't find their libraries and so I documented it.

The three main locations that will affect the library search are 1) /etc/SHLIBPATH; 2) environment variables; and 3) the embedded library search path.

Unfortunately, this is a drastic oversimplification: the best reference I have to offer is that article that brings everything together (in my opinion, any way).