This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [paul@parasoft.com] libc/1188: dlsym(RTLD_NEXT ...) returns non-default symbol
- To: aj@arthur.rhein-neckar.de
- Subject: Re: [paul@parasoft.com] libc/1188: dlsym(RTLD_NEXT ...) returns non-default symbol
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Fri, 2 Jul 1999 14:04:33 +1000
- CC: libc-alpha@sourceware.cygnus.com, paul@parasoft.com
- References: <u8u2rqwtty.fsf@arthur.rhein-neckar.de>
> From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
> Date: 30 Jun 1999 00:00:25 +0200
> #include <stdio.h>
> #include <dlfcn.h>
>
> FILE *_xx_fopen(const char *name, const char *mode)
> {
> FILE *(*chain1)() = dlvsym(RTLD_NEXT, "fopen", "GLIBC_2.1");
> FILE *(*chain2)() = dlsym(RTLD_NEXT, "fopen");
>
> if (chain1 != chain2) {
> fprintf(stderr, "fopen()s differ: %p vs %p\n", chain1, chain2);
> }
> return chain2(name, mode);
> }
>
> main()
> {
> char buf[1024];
>
> FILE *in;
>
> if ((in = _xx_fopen("/etc/passwd", "r"))) {
> while (fgets(buf, sizeof(buf), in)) {
> printf("%s", buf);
> }
> fclose(in);
> }
> return 0;
> }
The problem here is backwards compatibility. Try compiling this
program under glibc 2.0, run it under 2.1, and it will work. With the
proposed change it would fail.
Possible solutions are:
* version dlsym(), so that the GLIBC_2.0 dlsym() disregards newer
symbols---this is actually quite nice, because it means for instance
that an old program doesn't see (possibly unexpected) extra math
functions in libm, but it also means that we release a new dlsym()
for almost every tiny revision of the library (you could generate
these automatically from the versioning files, in fact you would
probably just list the chain of versions, GLIBC_2.1.1 -> GLIBC_2.1
-> GLIBC_2.0, and have some dlvsym_not_later_than, and have
`dlsym@@GLIBC_2.1(sym)' call `dlvsym_not_later_than(sym,
"GLIBC_2.1")'.
* inform the user that dlsym() will not work for symbols in libc,
libm, etc.---and why should it?
* somehow try to work out which symbol the program really wants,
for instance by looking in the object which is calling dlsym (yuk!)
to see what it thinks is the right symbol, then (if not found there)
looking in the application (double yuk!) or even on the symbol
search path (shudder). What happens if the object tries to use both
symbol versions I don't know.
--
Geoffrey Keating <geoffk@ozemail.com.au>