This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [paul@parasoft.com] libc/1188: dlsym(RTLD_NEXT ...) returns non-default symbol


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]