Re: HPUX shl_load fix for libtool.

[Gary V . Vaughan]

On Tuesday 20 March 2001  1:21 am, Ahmed Masud wrote:
> hi there:

Hi Ahmed.

> Just attaching a patch for libtool-1.3.5. that fixes a couple of HPUX
> bugs.

Great.  Thanks.  libtool-1.3.x is dead now, and 1.4 (from the CVS HEAD 
branch) is approaching, but your patch ports quite easily, so no matter in 
this case.

However, perhaps I will get run over by a bus on the way to work tomorrow 
morning... so, please at least Cc: the libtool-patches list so that your work 
isn't lost. ;-)

> Primary problem:
>
>       While trying to do a lt_dlopen(NULL); on HPUX so that I could
>       bind to any exported symbols (either from program or previously
>       loaded libraries) I encountered that the program locked up.

That is not the semantics of lt_dlopen(NULL), which should represent a handle 
to only the symbols in the main executable (not including the symbols of 
previously loaded modules).  Alexandre, please correct me if I am wrong here.

The reason for this is that the other module loaders do not provide this 
feature, so your program will not work unless it is compiled and executed on 
a box that provides the shl_load API (which presumably isn't what you want, 
otherwise you don't need libltdl in the first place).

HP-UX must be doing something wierd:  If I load two modules, each of which 
defines and exports a function called `name_clash', and I the use shl_findsym 
with a NULL module handle to return the address of `name_clash', which is 
returned?  Worse, what if the main executable *also* defines `name_clash'?  
If you could try something like that and let me know, I would be grateful -- 
hopefully, it doesn't just crash, or refuse to load the module or something 
hideous :(

> Solution:
>       As it turns out shl_load does not like NULL filename and gets into
>       a race condition.  The appropriate functionality is achieved
>       actually by passing a NULL handle to the shl_findsym and to not
>       call shl_load at all, whenever binding against preloaded symbols.

Interesting.  I was not aware of this.  Even if I am correct about the 
semantics of lt_dlopen() this has implications.

> Secondary Problem:
>       Whenever shl_findsym is called it wants a pointer to the handle
>       which in turn points to NULL; upon returning shl_findsym actually
>       changes the NULL to a valid handle.
>
>       However, this means that any subsequent calls to lt_dlsym with
>       the an lt_handle obtained by lt_dlopen(NULL) will not resolve
>       against libraries opened after the first call.

So I need to fetch and save a handle from the main executable before any 
other modules are loaded incase someone asks for lt_dlopen(NULL) after 
loading a few modules.  Yuck!

> Any how the attached patch, fixes the behaviour.

Thanks.  Please provide a ChangeLog entry, so that I can attribute you 
properly in the ChangeLog file.  I'll rework your patch, and commit it to 
soon-to-be-libtool-1.4  as soon as someone confirms or denies my 
understanding of lt_dlopen(NULL) semantics.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

libtool-1.3.5-1.3.5.1-patch
Description: Text Data