#3142 load command in HP (shl_load) picks wrong version of library

obsolete: 8.4.9

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

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!


  • Daniel Collins

    Daniel Collins - 2005-05-18

    Patch to ensure first shl_load doesn't use SHLIB_PATH

  • Kevin B KENNY

    Kevin B KENNY - 2005-05-20
    • assigned_to: kennykb --> hobbs
  • Kevin B KENNY

    Kevin B KENNY - 2005-05-20

    Logged In: YES

    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.

  • Daniel Collins

    Daniel Collins - 2005-05-23

    Logged In: YES

    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.

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-05-31
    • status: open --> pending
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-05-31

    Logged In: YES

    Is this resolved then?

  • Daniel Collins

    Daniel Collins - 2005-05-31
    • status: pending --> open
  • Daniel Collins

    Daniel Collins - 2005-05-31

    Logged In: YES

    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

    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.

  • Daniel Collins

    Daniel Collins - 2005-05-31

    Logged In: YES

    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.

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-10-05
    • status: open --> closed-fixed
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2005-10-05

    Logged In: YES

    Removal of the DYNAMIC_PATH for the first shl_load appears
    correct. I have commited that for 8.4.12 and 8.5a4.