Menu
▾
▴
#3142 load command in HP (shl_load) picks wrong version of library
closed-fixed
5
2005-10-05
2005-05-18
No
I think this is a follow on of several earlier bug reports in
this area (notably 611108, but also 217820, 219140).
If I run "load /home/dcollins/libtest.sl" within a stock
tclsh, it actually ignores the path I've given it and
searches SHLIB_PATH finding another copy of the
same library. This is causing lots of head scratching
during unit tests of our extensions, when any rebuilds
don't seem to have any effect!
I would expect it to use SHLIB_PATH, if I just run "load
libtest.sl", or if it couldn't find it in the full path area, but
not always!
This was observed on HP-UX 11i, Solaris and linux
seem to be behave as expected.
From looking at 611108, I assume the behaviour is
supposed to be as follows (but correct me if I'm wrong):
1. Convert the filename the user entered to a full native
pathname and use that to load the library.
2. If that fails, pass the original string the user entered
(raw filename, relative path or whatever) to the OS-
specific "dlopen" command and let it us
LD_LIBRARY_PATH/SHLIB_PATH to find a version of
that library.
I think that the implementation is correct for the
tclLoadDl.c and tclLoadDld.c (i.e. Solaris, Linux, etc)
but the HP implementation has a DYNAMIC_PATH flag
that tells it to always use SHLIB_PATH, even in step 1
above.
I've attached a patch that removes that flag for the first
call to shl_load (the one with the full native path), the
second call is left alone (since we want that to use the
dynamic path variable).
Can any other HP Tcl users' confirm/contradict that? I
don't claim to be an expert on this, its mostly been trial
and error, and I believe the whole shl_load mechanism
is being replaced by the more usual dlopen for 64-bit,
unfortunately we're stuck with 32-bit HP!
Patch to ensure first shl_load doesn't use SHLIB_PATH
Logged In: YES
user_id=99768
The DYNAMIC_PATH arg is needed so that if you do
load /path/to/foo.shl
and foo.shl has a ref to some libbar.shl, that the
dynamic linker will search the SHLIB_PATH for it.
Or that's my understanding of why DYNAMIC_PATH
got put there in the first place (Bug 219140).
I don't have an HP-UX machine, forwarding to someone
that does.
Logged In: YES
user_id=1093010
Ah, I hadn't realised that. If that's the case, then I can see
why its necessary.
I'll play around with my test program a bit more then.
Logged In: YES
user_id=72656
Is this resolved then?
Logged In: YES
user_id=1093010
I thought that was what the +s option on the linker was for
though? Each binary and shared library has a flag that
defines whether it uses SHLIB_PATH or has embedded
paths to find associated libraries
manpage for shl_load states:
DYNAMIC_PATH: Allow the loader to dynamically search for
the library specified by the path argument.
The directories to be searched are determined by the +s and
+b options of the ld command used when the program was
linked.
That suggests to me that if we are giving it a complete path,
we don't need the flag, it only becomes useful if we give it a
partial path.
I don't claim to be an expert on HP's loading policies, it just
seems odd that the end-user behaviour is different on HP
than on Solaris for example.
Feel free to downgrade the priority, its quite a low priority
thing, I'd just feel happier if the behaviour was consistent
across the platforms.
Logged In: YES
user_id=1093010
Forgot to mention, the fix for Bug 219140, when
DYNAMIC_PATH was added in the first place, was back
when only a single load attempt was made for any given
shared library.
Now, we do the "try a complete path, THEN try the path that
the user entered" approach, I think we don't need
DYNAMIC_PATH in the first attempt. If we leave it in the 2nd
attempt, that should keep the original behaviour as it was
before the 2-phase approach was added.
Logged In: YES
user_id=72656
Removal of the DYNAMIC_PATH for the first shl_load appears
correct. I have commited that for 8.4.12 and 8.5a4.