This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Bug in dlsym() (scope problem(?) & RTLD_NEXT problem)
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 13 Oct 1998 22:33:38 -0700
> smurf@noris.de (Matthias Urlichs) writes:
>
> > Does anybody know how other OSes, esp. Slowaris, handle this?
>
> Solaris does not STB_WEAK different from STB_GLOBAL in ld.so. It only
> handles it differently in ld. This is strict following to the ELF
> standard. Means, the ELF standard does not say anything about ld.so
> handle STB_WEAK.
>
> This makes the whole situation even more complicated.
>
> Any suggestions? For the ld.so handling I say nothing should (must?)
> be changed. The GNU ld.so handling is much more powerful. For
> RTLD_NEXT, I still think the current behaviour is correct since the
> lookup should in any case be the same performed by ld.so during the
> implicit relocations.
So long as, from a preloaded object, it is possible to find the libc
(or whatever) definition of a function defined by the preloaded
object.
That is, something like the following must work:
#include <unistd.h>
#include <dlfcn.h>
#define NXTFUNC \
do { \
if (!next_func) \
{ \
next_func = dlsym(RTLD_NEXT, __FUNCTION__); \
if (next_func == NULL) \
return -1; \
} \
} while (0)
int
unlink (const char *file)
{
static int (*next_func)(const char *file) = NULL;
NXTFUNC;
return next_func(file);
}
and have no visible effect when it's added as a LD_PRELOAD object, no
matter what function is overriden. Many people expect and rely on
this.
In fact, at present there is a problem using this to override
versioned symbols. I'm not sure how to deal with this.
--
Geoffrey Keating <geoffk@ozemail.com.au>