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
