Re: HPUX shl_load fix for libtool.

[Gary V . Vaughan]

I'd like to get this in before 1.4 is released...

Any thoughts?

Cheers,
        Gary.

On Tuesday 20 March 2001  3:35 am, Gary V. Vaughan wrote:
> 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.

----------------------------------------
Content-Type: text/x-c; charset="us-ascii"; name="libtool-1.3.5-1.3.5.1-patch"
Content-Transfer-Encoding: base64
Content-Description: 
----------------------------------------

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