Glibc Versioned Symbols

[Bob Proulx]

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