Re: LD_PRELOAD odd woes

From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 11/11/04

  • Next message: Sherman: "linux timer question" 
    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
    > is.

    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, ...).

    Cheers, 

    -- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
  • Next message: Sherman: "linux timer question"