Re: 329-gary-allow-RTLD_GLOBAL

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Sun, Apr 08, 2007 at 12:53:01PM CEST:
> On 8 Apr 2007, at 01:56, Bob Friesenhahn wrote:
> >On Sun, 8 Apr 2007, Ralf Wildenhues wrote:
> >>First, many many thanks for attacking this.
> 
> No problem.  I plan to spend a day or so each week tackling all of the
> showstoppers so we can put out a final alpha release.

Maybe I can make some time to tackle one of them, too.  No promises
though.

> Incidentally, I'm don't know whether it would be wiser to go from 2.1a
> to 2.2 when we do release to keep in line with our own version 
> numbering
> scheme, or whether it will be okay to release 1.9h from HEAD and reset
> the number to 1.9i in CVS in readiness for a 2.0 release.  Thoughts?

I think we should release 2.1b next, then 2.2.  2.1a has been floating
around a lot, and if we reset it now, then going to 2.1 again later will
be confusing.

> >>Next, please be aware that as important as documentation would be
> >>test exposure  for the functionality.
> 
> I have no idea how to write a reliable test for this.  I can certainly
> test that the API is available,

Yes.  That's the first test that needs to be done: just simply have a
test that calls each new function at least once.

> but since the best semantics I can
> provide are "instead of the default symbol visibility request that the
> underlying dlloader use global or local symbols at load time, iff that
> is supported by the host OS and the underlying dlloader 
> implementation".

I won't mind if such a test is specific to dlopen for now, or even to
GNU/Linux.  I can write it if you like.

> Maybe I should test for the system default, and add a test that tries
> to change it and succeeds only if lt_dlissym{global,local} fail, or
> the default symbol visibility is successfully overridden.  That's
> probably more work than the patch itself though!

Yuck.

> Is there an easy way of composing a opaque object to pass to the api  
> that doesn't add unnecessary complication.  I don't really like this
> (stupid symbol names aside):
> 
>    lt_dlopaque opaque = lt_dlopaque_new();
> 
>    lt_dlset_symglobal (opaque);
> 
>    handle = lt_dlopenopaque ("libmod.la", opaque);

But this is how it can be extended without breaking API!  Only if
lt_dlopaque is a pointer type, of course, and also you need to free the
object later on.

And IIUC then this is how pthread works, too, no?

> Compared to:
> 
>    handle = lt_dlopenflags ("libmod.la", LT_DLSYMGLOBAL);
> 
> Although I'm open to persuasion.  Or did you have something else in  
> mind?

No, I think that comes close to it.

Cheers,
Ralf