Re: Forcing static link of libstdc++

[Bob Proulx]

Mike Melanson wrote:
> It's possible that I'm chasing after the wrong solution. This is a more 
> specific problem:
> 
> * I have a proprietary program that I am trying to build to run on a 
> wide variety of Linux/x86-based distributions.
> 
> * The build process links against libstdc++.so.6 on the build machine.
> 
> * The program fails to run on older systems that only have libstdc++.so.5.
> 
> * Thus, I have been seeking to statically link libstdc++.so.6 inside the 
> binary. Not sure if this is the right or optimal solution, though 
> previous versions of this same program -- using an ad-hoc Makefile 
> solution -- took this route.

What I suggest is to bundle up all of the shared libraries called by
the application and then including them in your installation bundle.
If your only issue is ancillary shared libraries then simply reference
them through LD_LIBRARY_PATH set in a invoking wrapper script.

But for the me and I think for you as well but you just have not hit
it yet the problem is libc which houses the dynamic linker which links
in the other libraries.  The older systems will have an older libc and
I have built against a newer one.  Therefore I need to bundle the
linked-against libc for those machines.  I am installing centralized
applications on a shared NFS filesystem.

Unfortunately libc is the one library that cannot be overridden by
LD_LIBRARY_PATH.  But it can be selected explicitly by invoking ld.so
directly using the --library-path option.  I do this routinely for the
same reasons as you list and it works quite well.

Given the following setup copy the newer glibc and lib 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.  Include with libc all of the shared libraries that
are specific to the program and desired to be used instead of the
system installed versions.  This allows a program compiled on a newer
machine with newer libraries to run on older machines.  This allows a
program to be system distribution neutral.

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/lib/libstdc++.so.6 # your specific example lib
  ./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.  If something is not clear feel free to ask further
questions.

Bob

P.S. This does not seem to be a very well known technique.  In fact it
seems to be a best kept secret because I have seen this question asked
a few times and have been posting essentially this same information in
a few different places.

  http://gcc.gnu.org/ml/gcc-help/2006-07/msg00126.html
  http://svn.haxx.se/users/archive-2005-05/1727.shtml

But this is basically old news.  Here is a useful Reference:

  http://www.novell.com/coolsolutions/feature/11250.html