[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-18 18:15:42
[Download RAW message or body]
Hi!
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.
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic