/usr/lib/dld.sl

[Linda Lux]

results of nm -pxAN /usr/lib/lib*|grep JudySLIns:
nm: /usr/lib/lib.b: bad magic
/usr/lib/libJudy.a: 0x000001f8 T JudySLIns
/usr/lib/libJudy.sl:0x00024388 T JudySLIns
/usr/lib/libJudy.sl:0x00024328 T JudySLIns
nm: /usr/lib/libU77.alias: bad magic
nm: /usr/lib/libU77.alias.i8: bad magic
nm: /usr/lib/libU77.alias.r8: bad magic
nm: /usr/lib/libU77_.alias: bad magic
nm: /usr/lib/libbomb.a: cannot open
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
nm: /usr/lib/libp: cannot open

[Dennis Handly]

Is this executable /usr/lib/libJudy.sl?
Does /tmp/ismp008/libhpuxppk.1 have a dependency on libJudy.sl?

[Linda Lux]

this is what I have in /usr/lib:
-r--r--r-- 1 bin bin 233910 Sep 22 2005 libJudy.a
-r-xr-xr-x 1 bin bin 204800 Sep 22 2005 libJudy.sl

and I cannot answer the second question as it is generated from the application.
I have the engineers of the application also looking at this, but I wanted to make sure I didn't have soemthing in error with my system.

[Dennis Handly]

>I cannot answer the second question

chatr /tmp/ismp008/libhpuxppk.1
Do you see libJudy here?

[Linda Lux]

results of chatr libhpuxppk.1
libhpuxppk.1:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared library list:
static /usr/lib/libc.1
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 enabled
shared library private mapping disabled

[Dennis Handly]

>results of chatr libhpuxppk.1
>shared library list:
>static /usr/lib/libc.1

I don't see libJudy.sl. If a shlib is going to use another, it should either be a dependency or the caller of libhpuxppk.1 needs to have it.

Also, something else is seriously wrong. This shlib should NOT have libc.1. libc.1 is for 10.x applications and isn't supported when mixed with 11i executables and shlibs.

[Linda Lux]

my SHLIB_PATH has:
/usr/lib:/etc/opt/resmon/lib:/opt/gnome/lib

so if this has libc.1 then it is in the application software and needs to be changed?

[Dennis Handly]

>my SHLIB_PATH has: /usr/lib:/etc/opt/resmon/lib:/opt/gnome/lib

This is unrelated to SHLIB_PATH.

>so if this has libc.1 then it is in the application software and needs to be changed?

I said two things:
1) libJudy must either be on libhpuxppk.1 or the executable.
2) It is illegal to use libc.1 in your application that was developed on 11i. I.e. libJudy wasn't there for 10.x so it implies you are mixing libc.2 with libc.1.

[Dennis Handly]

If not obvious, since libhpuxppk.1 has two strikes against it, it should be relinked with -lJudy and remove libc.1 completely and not replace it by -lc.

[Linda Lux]

Dennis
I apologize - I am not an educated system admin, I am a "learned" admin, so I am unsure what you are telling me.
and so I cannot relay to the Unix developer of the application what is wrong.
Could you explain further as I believe this could resolve my problems.