Matthew Woehlke wrote: > Apparently selectively shadowing libc is non-trivial... any > suggestions/hints?
Not so much non-trivial as perhaps non-obvious. The dynamic loader is part of libc and so by the time the program tries to use LD_LIBRARY_PATH it is already too late because it has already loaded the system libc. Therefore LD_LIBRARY_PATH is not useful for overriding libc and only works for non-libc libraries. To override libc you have to call the ld.so directly. Also you don't want LD_LIBRARY_PATH to hang around causing trouble for other children processes that might need something still different so you want to use the --library-path option instead, then there is no lingering smell. Given the following setup with copies of glibc and other lib files in a local "sandbox". ./mylib/ld-linux.so.2 ./mylib/libc.so.6 ./mylibexec/myprog Then this script in ./mybin/myprog works: #!/bin/bash MYAPPDIR=$(dirname $(dirname $0)) exec -a $MYAPPDIR/mybin/myprog $MYAPPDIR/mylib/ld-linux.so.2 --library-path $MYAPPDIR/mylib $MYAPPDIR/mylibexec/myprog "$@" Using the bash specific 'exec -a ALIAS' works well here. It keeps the application itself from knowing that it has been overridden. It does not need to know, and depending upon the application knowing would confuse it, such as when it tries to use $(dirname $0) for any reason. The key points are: * Call the ld.so (aka ld-linux.so.2) directly * Don't use LD_LIBRARY_PATH (because it messes up later progs) * Put the real program off to the side and use a wrapper * Use 'exec -a NAME' to hide this from the program itself Here are pointers to previous messages that I have posted about how to use ld.so wrapping to get a particular libc. http://gcc.gnu.org/ml/gcc-help/2006-07/msg00126.html http://svn.haxx.se/users/archive-2005-05/1727.shtml Hope that helps! Bob _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
