[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RTLD_NEXT now a GNU extension?
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-20 8:07:07
[Download RAW message or body]

   Hi!

On Fri, May 19, 2000 at 07:47:57AM +0200, Stephan Kulow wrote:
> Stefan Westerfeld wrote:
> > On Thu, May 18, 2000 at 11:49:01AM -0700, Waldo Bastian wrote:
> > > On Thu, 18 May 2000, pbrown@redhat.com wrote:
> > > > As of GLIBC 2.2, the RTLD_NEXT #define in dlfcn.h has become an extension,
> > > > and is only defined if __GNU_SOURCE is defined.  At least artsc/artsdsp.c
> > > > makes use of this definition.
> > > >
> > > > Is there a more portable way to compile this, or on Linux will we have to
> > > > define __GNU_SOURCE.
> > >
> > > What does RTLD_NEXT do?
> > 
> > It allows you to get references to the "original" symbols which you have
> > redefined via LD_PRELOAD. It is used in artsdsp, which works like this:
> > it redefines open, close, write, ioctl and similar functions to it's own
> > routines. Then, it "catches" accesses to /dev/dsp and forwards the requests
> > to aRts, while it lets others pass.
> > 
> > This means, you can do things like this to make some apps output via aRts:
> > 
> > artsdsp xmms
> > artsdsp esd
> > 
> > There seem to be only three ways of doing this.
> > 
> > a) you know another name for the original symbol, which is what I used to
> >    do before - thus, open called __open, and so on - however, this isn't
> >    compatible between glibc2.0 and glibc2.1 - this solution is also bad,
> >    because it will not allow chaining preloaded hacks like artsdsp
> > 
> > b) you save the original symbols upon start - there is a way to do this in
> >    an init function, which is called by LD_PRELOAD, don't know how it works
> > 
> > c) you use dlopen with RTLD_NEXT, which is what artsdsp does
> > 
> > I'd recommend defining __GNU_SOURCE inside artsdsp only, if that makes glibc2.2
> > happy.
> > 
> Nope, this would be as unportable as using __open directly :)
> 
> I would suggest d) - using 'handle = dlopen(LIBC); dlsym(handle, "open");' 

This will break preload chaining (e.g. if you use another preload to redirect
your serial port to some network server, which also redefines open). So if we
want to support configurations which are that weird, a possible solution would
be

  getenv("LD_PRELOAD")
  handle = dlopen("preload in LD_PRELOAD before this" or LIBC)
  dlsym(handle,"open")

Would that be better, then? What is a portable way for getting the path to
libc? I saw under linux you can use LIBC_SO, does this work for other
platforms as well?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

[prev in list] [next in list] [prev in thread] [next in thread]