Re: 329-gary-allow-RTLD_GLOBAL

[Ralf Wildenhues]

* 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