[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forcing static link of libstdc++

From: Bob Proulx
Subject: Re: Forcing static link of libstdc++
Date: Thu, 21 Sep 2006 23:47:27 -0600
User-agent: Mutt/1.5.9i

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 on the build machine.
> * The program fails to run on older systems that only have
> * Thus, I have been seeking to statically link 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
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


Then this script in ./mybin/myprog works:

  MYAPPDIR=$(dirname $(dirname $0))
  exec -a $MYAPPDIR/mybin/myprog $MYAPPDIR/mylib/ --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/  #
  ./myproject/lib/      # glibc
  ./myproject/lib/ # 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


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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]