[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 329-gary-allow-RTLD_GLOBAL
From: |
Ralf Wildenhues |
Subject: |
Re: 329-gary-allow-RTLD_GLOBAL |
Date: |
Sun, 8 Apr 2007 19:03:18 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* 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
- 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/04/07
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/04/07
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/04/07
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/04/08
- Re: 329-gary-allow-RTLD_GLOBAL,
Ralf Wildenhues <=
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/04/08
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/04/09
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/04/09
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/04/10
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/04/10
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/04/10
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/04/10
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/04/10