Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd

[Matthew Woehlke]

Bob Proulx wrote:
> 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!

Nope. I think that amounted to "ok, this doesn't work on Linux".

Aside from the fact that I need LD_LIBRARY_PATH for other reasons 
(although not for libc), I have... 267 programs that need glibc_2.3. 
Creating that many wrapper scripts (even that many symlinks to a single, 
general-purpose wrapper script) would be messy. Trying to *maintain* it 
if/when I add or change programs would be a nightmare. So if I can't fix 
it by tinkering with the environment, then I guess I am going to give 
up. (Oh, and even if this was just one program, I can't get your trick 
to work either, it still tries to use /lib/i686/libc.so.6.)

I don't understand why applying such a change globally would be bad, 
though. How is it any different from simply updating the system libc?

--
Matthew
"Have you tried that new mixed drink, 'GDR'"?
"What is it?"
"Gin, Duck and Rum. It tastes fowl."