Ian Lance Taylor wrote: > Browder, Tom writes: > > When I try to run my program (compiled with g++ 4.1.1) which uses 2.4 of > > GLIBC on another machine with only GLIBC v 2.3 I get an error message > > about "...version 'GLIBC_2.4' not found." > > > > Is there any way to work around this short of upgrading glibc on the > > target host? (Or downgrading on the development host?) > > No. glibc is backward compatible, but not forward compatible. Agreed. However, it is possible to run a newer glibc from a non-/lib location by invoking the program using the ld.so directly. What are you trying to do? Are you trying to run your own compiled one-off program? If something for your own use then I believe running the ld.so directly with --library-path through a script wrapper will work fine for you. I do this all of the time. Given the following copy the newer glibc parts to that location. ./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 "$@" This allows you to run a specific glibc independent of the one installed in /lib. I usually create a directory named after the program. I usually don't call them "my"bin but just have them called "bin", "lib", "libexec", etc. I used the "my"dirs above to emphasize that this is not a system installed location. ./myproject/lib/ld-linux.so.2 # ld.so ./myproject/lib/libc.so.6 # glibc ./myproject/libexec/myprog # compiled binary ./myproject/bin/myprog # wrapper script to launch it You should pick the right version with respect to tls, nptl, etc. Hope that helps, Bob
