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
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
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
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!