Re: glib / Tru64 v.5.0 interaction bug report & workaround

[Tim Janik <timj gtk org>]

On 2 Feb 2001, Jeremy H. Brown wrote:

> The man page for dlopen on my machine says:
> ------
>   If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, RTLD_GLOBAL will be
>   assumed. However, unlike explicit use of RTLD_GLOBAL, this default mode
>   will allow dynamic rebinding of symbol addresses and recalculation of
>   dynamic relocations as shared libraries are loaded or unloaded.
> ------
> 
> >From this, I think that on this particular OS, you can safely omit
> RTLD_GLOBAL -- so my inclination is to suggest that you auto-detect
> tru64 unix and bind RTLD_GLOBAL to 0 in that special case.  (I think
> you're almost certainly right that this is a Tru64 bug.)

i'm pretty positive on this being a tru64 bug as well. btw, most
systems that implement dlopen() default to RTLD_LOCAL if neither
flag is specified.
however, here's an excerpt from the signle unix spec V2:

> RTLD_GLOBAL
> The object's symbols are made available for the relocation processing of any
> other object. In addition, symbol lookup using dlopen(0, mode) and an
> associated dlsym() allows objects loaded with this mode to be searched.
> 
> RTLD_LOCAL
> The object's symbols are not made available for the relocation processing of
> any other object.
> 
> If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, then an
> implementation-specified default behaviour will be applied.
> 
> If a file is specified in multiple dlopen() invocations, mode is interpreted
> at each invocation. Note, however, that once RTLD_NOW has been specified all
> relocations will have been completed rendering further RTLD_NOW operations
> redundant and any further RTLD_LAZY operations irrelevant. Similarly note
> that once RTLD_GLOBAL has been specified the object will maintain the
> RTLD_GLOBAL status regardless of any previous or future specification of
> RTLD_LOCAL, so long as the object remains in the address space (see
> dlclose()).

there's no notion that RTLD_OPEN on a module should "redirect" symbol
lookups on that module's handle to the main (NULL) module (which is
pretty brain damaged btw).

for GModule, we can probably disable RTLD_GLOBAL alltogether for Tru64
on the basis of "it's utterly broken there anyways", for that however,
i need a way to detect your system.

please send me (privately), the output of:
$ gcc -E -dM -x c /dev/null
or equivalent to get default macros defined by your compiler,
$ uname -a
and also a copy of your <dlfcn.h>.
additional information to spot 4.0D which as you say doesn't
have this problem will also be helpfull.

[further discussion of this should really go on on gtk-devel-list gnome org]

> 
> Jeremy
> 

---
ciaoTJ