Tcl Source Code

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!

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.

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=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=72656

Is this resolved then?

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=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.

File Added - 134978: shl.diff