Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

obsolete: 8.4.9
closed-fixed
Jeffrey Hobbs
5
2005-10-05
2005-05-18
Daniel Collins
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!

Discussion

1 2 > >> (Page 1 of 2)
  • Daniel Collins
    Daniel Collins
    2005-05-18

    Patch to ensure first shl_load doesn't use SHLIB_PATH

     
    Attachments
  • 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
    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.

     
  • Daniel Collins
    Daniel Collins
    2005-05-23

    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.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2005-05-31

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

    Logged In: YES
    user_id=72656

    Is this resolved then?

     
  • Daniel Collins
    Daniel Collins
    2005-05-31

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

    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.

     
  • Daniel Collins
    Daniel Collins
    2005-05-31

    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.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2005-10-05

    • status: open --> closed-fixed
     
1 2 > >> (Page 1 of 2)