Re: LD_PRELOAD odd woes
From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 10 Nov 2004 16:48:41 -0800
Drago <Drago@mailinator.com> writes:
> I had this idea that if I could intercept calls to fopen, I could se
> if the file name I supplied in the configuration file was trying to be
> opened, and if so, merely return a FILE* handle to /dev/stdout.
That should work.
> So to test this, I wrote this fopen relacement: [...]
> Then, I try to compile something, and the compiler hangs. This tells
> me that I am doing something horribly wrong, and I am missing what it
One problem is that you are probably getting the "wrong" fopen().
There are at least 2 fopen()s in libc:
$ nm -n /lib/libc.so.6 | grep ' fopen[^a-z0-9]'
00052820 T fopen@@GLIBC_2.1
00054da0 T fopen@GLIBC_2.0
There is a high chance that 'dlsym(..., "fopen")' returns you the "old"
fopen(), when your program needs the "new" one (to match e.g. fclose(),
which also has 2 different versions).
Which version you actually get from dlsym() depends on your version
of glibc :-( You can work around this problem by using dlvsym() instead.
The second problem with your approach is that /lib/libc.so.6 may
not be the right libc. On modern systems, /usr/tls/libc.so.6 or
/usr/i686/libc.so.6 may be more correct. You can fix this problem
by using dlsym(RTLD_NEXT, ...).
-- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email.