Howard Chu writes:
Running something in the configure script would work for me. Has anyone ever did something like this? Such as, determining that lt_dlopenext() ends up really opening "libc.so.6", so that's what I really need to open?None of this guesswork should be needed. Since the main program already depends on libc, you should be able to lt_dlopen(NULL) and reference the main program to find libc's symbols.
My use case is intercepting a main application's calls to library functions. I set LD_PRELOAD to preload my own shared library which provides replacement symbols for socket(), connect(), etc…
My wrapper needs to find the real socket() and connect(). I haven't checked this yet, but I suspect that since my shared library was loaded ahead of libc, after lt_dlopen(NULL), using lt_dlsym() will simply return a pointer to my own symbols, rather than libc's.
pgp2tPrbZGJSs.pgp
Description: PGP signature
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
