errors from dld.sl

[Candace Ordaz]

Our development machine:HP-UX marvin B.11.00 E 9000/871 2005096159 8-user license
Our customer's machine:HP-UX omlcdb99 B.11.00 A 9000/800 (ta)
We've had an application compiled and running on 10.20 with this customer for about 5 years. We're trying to get them to upgrade to 11 and compiled the same app on our 11 development machine(it runs fine) and attempted to start on their 11 machine. We get the following error:
/usr/lib/dld.sl: Can't open shared library: /usr/lib/dld.sl: Can't open shared l
ibrary: /u00/app/oracle/product/8.1.7/lib//libwtc8.sl
/usr/lib/dld.sl: No such file or directory
/u00/app/oracle/product/8.1.7/lib//libwtc8.sl
/usr/lib/dld.sl: No such file or directory
/usr/lib/dld.sl: Can't open shared library: /u00/app/oracle/product/8.1.7/lib//l
ibwtc8.sl
/usr/lib/dld.sl: No such file or directory

Naturally, the library is there or I wouldn't be sending this message. We tried chatr -s and creating a SHLIB_PATH but that didn't make any difference. My research has just left me confused about the way HP is using SHLIB_PATH and LD_LIBRARY_PATH in 11. We had this problem a year ago with another customer but in their case the chatr -s worked until we were able to recompile with OS_LDFLAGS -v -Wl, +s which eliminated the problem for them. I don't want to recompile this until I understand why chatr -s didn't fix it this time so I know that a recompile will work. I've also been confused about why this library shows up this way on HP when it doesn't on my Solaris or AIX executables but if we get it to work on their machine I'll stop wondering about it again.

[Mike Stroyan]

The command to enable SHLIB_PATH is "chatr +s enable a.out" rather than "chatr -s".
The LD_LIBRARY_PATH environment variable was not used by dld.sl on 11.00 until patch PHSS_22478 or later.
You should have your customer check their 11.00 patch level for dld.sl, or just have them try a current patch such as PHSS_28434.
When you look at the "shared library list" with chatr you may see that some shared libraries used by your program are labelled "static" instead of "dynamic". If you link with an absolute path to a shared library file instead of a "-llibname" option then the linker will make dld.sl look for that library at a specific location. That can be changed after linking with the "chatr +l" option.
You could have them use the tusc system call tracer to see exactly where your program is looking for the shared library. That could give you a better idea why the library is not found. Tusc is available from
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1433,00.html

[Candace Ordaz]

First, thanks for the response. I'm still trying to comb through all the metalink stuff but it was useful for the difference between SHLIB_PATH and LD_LIBRARY_PATH.
Second, (because we're all sooo sensitive about these things) I really did mean chatr +s (although I wish it were that easily solved), I was typing without thinking. I did go back and make sure that I relayed that correctly to the people on the other server, just in case. Since this is a customer box and I'm the sys admin on our side, the sequence is that I tell the-guy-on-our-side-who-actually-talks-to-the-customer and he tells her what to do and then she does it and reports back. It now appears that although they may have correctly done the chatr +s enable , her profile doesn't have the correct SHLIB_PATH in it. At least the one she emailed me doesn't. I'm waiting to clear that up while I sort out patches and revisions and versions and still try to understand why this happens. I panicked when it appeared that the chatr +s didn't work this time since that gave the appearance that the problem was different from the last occurence.