[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: |
Tue, 22 May 2007 14:48:00 +0200 |
User-agent: |
Mutt/1.5.15 (2007-05-20) |
* Gary V. Vaughan wrote on Tue, May 22, 2007 at 02:24:25PM CEST:
> On 22 May 2007, at 13:16, Ralf Wildenhues wrote:
>> * Gary V. Vaughan wrote on Tue, May 22, 2007 at 02:11:03PM CEST:
>>>
>>> I'm wondering how to best warn people who have their project
>>> build rely on RTLD_GLOBAL that what they are doing is inherently
>>> non-portable.
>>
>> Erm, relying on RTLD_LOCAL is non-portable.
>
> It is? You mean that relying on identical symbols from two dlopened
> modules to not clash is non-portable?
Well. I should have been more specific. Relying on lt_dladvise_local
to provide you with symbol hiding is not portable. Simply because
dlpreopening will not do that.
> On what architectures?
In most static-only settings. (With glibc you can sometimes still use
dlopen in a static link but only if you have the shared libc available
at runtime.)
It seems to me that dld does not provide symbol locality either, see
eleven-year-old <http://www.delorie.com/gnu/docs/dld/dld.html>.
>> Relying on RTLD_GLOBAL is not; after all, dlpreloading offers similar.
>
> Relying on RTLD_GLOBAL exported symbols to resolve undefined symbols
> in subsequently dlopened modules doesn't work on windows, or AIX. That
> seems pretty non-portable to me...
It doesn't work on AIX with runtimelinking? That would be news to me.
Using modules on AIX without runtimelinking seems pretty obscure to me.
>> But also relying on
>> allowing undefined symbols in your link is non-portable. I don't see
>> how you can distinguish cases here reliably, in an automatic way.
>
> Except for annoyance to the end-user, I was originally thinking that
> we don't need to distinguish. When the developer's libltdl client
> code calls lt_dladvise_global, we could have it emit a warning to
> stderr that says: If what you are trying to do won't work without
> calling lt_dladvise_global(), then you're code will not be fully
> portable.
Hmm. That will be informative the first time, and annoying the next
million times, if the user chose to accept this limitation. So yes,
a documentation patch is better. That way not only the fact about
some unportability but also its intensity may be conveyed. ;-)
Cheers,
Ralf
- Re: 329-gary-allow-RTLD_GLOBAL, (continued)
- Re: 329-gary-allow-RTLD_GLOBAL, Eric Blake, 2007/05/09
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/21
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/21
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL,
Ralf Wildenhues <=
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22