- Integrated Systems
- About Us
- Integrated Systems
- About Us
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
02-16-2009 09:24 AM
/usr/lib/dld.sl: Unresolved symbol: JudySLIns (code) from /tmp/ismp008/libhpuxppk.1
/usr/lib/dld.sl: Call to __sigenable() failed
/usr/lib/dld.sl: Not owner
Solved! Go to Solution.
02-16-2009 09:29 AM
It would help to know what application you are tying to install.
Owner of ISN Corporation
02-16-2009 04:26 PM
Hope this helps you,
02-17-2009 06:08 AM
Permissions? I know nothing about compiling and libraries and all that, but I would start by looking at permissions, I think.
02-17-2009 06:14 AM
dr-xr-xr-x 22 bin bin 8192 Jan 21 11:03 usr
dr-xr-xr-x 39 bin bin16384 Feb 12 11:28 lib
-r-xr-xr-x 1 bin bin 393216 Dec 8 09:37 dld.sl
which I believe is correct
02-17-2009 08:41 AM
Can you scan the library to see if it has that entry?
nm -pxAN /usr/lib/lib* | grep JudySLIns
That "Not owner" message is a little scary.
02-17-2009 08:47 AM
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
nm: /usr/lib/libp: cannot open
02-17-2009 09:11 AM
-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.
02-17-2009 09:33 AM
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared library list:
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
02-17-2009 09:43 AM
>shared library list:
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.
02-17-2009 09:48 AM
so if this has libc.1 then it is in the application software and needs to be changed?
02-17-2009 10:04 AM
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.
02-17-2009 10:06 AM
02-17-2009 12:18 PM
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.
02-17-2009 05:07 PMSolution
This has nothing to do with sys admin. It is HP-UX software development.
>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?
You can point them to this thread and it should be obvious.
As I mentioned the two problems:
1) If you are going to use libJudy functions, you need to add -lJudy to the shared lib or executable that uses them.
2) You absolutely can't link libhpuxppk.1 with /usr/lib/libc.1. It should be linked against -lc, or not at all.
Both these problems have to be fixed by relinking libhpuxppk.1 and changing the link line.