Re: 329-gary-allow-RTLD_GLOBAL

[Gary V. Vaughan]

On 22 May 2007, at 13:48, Ralf Wildenhues wrote:

* 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>.

ACK.  Thanks for clarifying :-)

Relying on RTLD_GLOBAL is not; after all, dlpreloading offers similar.

Relying on RTLD_GLOBAL exported symbols to resolve undefined symbols

seems pretty non-portable to me...

in subsequently dlopened modules doesn't work on windows, or AIX. That

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.

correct) in the test case I just patched, AIX can't build moddepend with
undefined symbols.

RTLD_GLOBAL can be passed to dlopen, but (assuming my recollection that AIX is one of the hosts that requires all symbols to be resolved at link time is

But also relying on

how you can distinguish cases here reliably, in an automatic way.

allowing undefined symbols in your link is non-portable. I don't see

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.  ;-)

Indeed!

Cheers,
        Gary
--
  ())_.              Email me: [EMAIL PROTECTED]
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part