How to statically link to libstdc++. Friends who like to upgrade GCC come and have a look.

linking libstdc++ statically

Christopher Baus writes about his problems linking libstdc++. Yes, making C + + binaries that would work properly in different Linux distributions is somewhat painful. The problem is isn't so much linking libstdc++ Statically–it are just a library after all–but the runtime support Ed by C + + code in general, to enable features like RTTI and exception handling.

The runtime support code used by different parts of a C + + application needs to be compatible. Needs to dynamic_cast or catch objects provided by another, both parts must agree on certain IM Plementation details:how to find vtables, how to unwind the stack, and.

For C + + and a few other GCC-supported languages with similar features, such details are specified by a C + + AB I.whenever the ABI used by GCC changes, you'll end up with incompatible libraries produced by the different GCC Versi Ons. The same is true for plain C, but the C-ABI is very much simpler and has been-around a lot longer so it ' s fairly stable.

As far as I know C + + ABI changes have been introduced with every major release of GCC (i.e. those with different or second version number components). To make matters worse, most major Linux distributions use GCC snapshots and/or patch their GCC versions, making it virtual ly impossible to know exactly what GCC versions you might is dealing with when you distribute binaries.

This is the problem cannot, in general, is solved by linking statically. The "All", code compiled against different ABIs is simply not binary compatible. It doesn ' t matter if you are manage to link binary incompatible code together, because it'll never work. Secondly, the language runtime support typically rely on some data being shared, e.g. to access some kind of lock or Globa L data structure (similar to how C programs need a shared errno).

Shared data implies that whenever more than one part of a program needs the runtime support, and any those parts is dyn Amically loaded, the runtime support needs to be loaded dynamically. Otherwise, the different program parts would end-with copies of the the data rather than one shared instance. That's the reason for putting the language runtime support code into a dynamic library by default.

There are many different workarounds and no perfect solution, but a fairly workable compromise are to link all C + + code int O ' executable while using dynamically loaded C-Libraries only. This way there are only one part of the program that needs the C + + runtime support mechanisms, which can therefore be Linke D in statically. You can mix and match statically and dynamically linked C libraries, but no C + + code (or any code using the C + + runtime Su Pport) may be linked dynamically if it to work.

Now, the practical problem people run in when trying to link libstdc++ statically are thatg++, the GCC front-end for comp Iling and linking C + +, adds the proper libraries and start-up code for C + + automatically and would link some of this code D Ynamically By default:

g++-o example example.cpp

ldd example
    linux-gate.so.1 =>  (0xffffe000)
    libstdc++.so.6 =>/usr/ Lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.so.6 (0xb7f17000)
    libm.so.6 =>/lib/libm.so.6 (0xb7ef3000)
    Libgcc_s.so.1 =>/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so.1 (0xb7eea000)
    libc.so.6 => Libc.so.6 (0xb7dd0000)
    /lib/ld-linux.so.2 (0xb7feb000)

The resulting binary links to a shared version of libstdc++, the standard C + + library, and a shared version of LIBGCC, a G CC Runtime Support library required for exception handling among the other things. This binary won ' t work on a machine with different versions of those libraries, but since it doesn ' t need Cally loaded C + + libraries, the incompatibility can is removed by linking libstdc++ and LIBGCC statically.

Consulting the GCC man page and you'll find the GCC option-static-libgcc mentioned. It makes the compiler link LIBGCC statically rather than. Except when it doesn ' t:

g++-static-libgcc-o Example Example.cpp ldd example linux-gate.so.1 =>  (0xffffe000)
    libstdc++. So.6 =>/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.so.6 (0xb7f17000)
    libm.so.6 =>-/lib/libm.so.6 ( 0xb7ef3000)
    libgcc_s.so.1 =>/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so.1 (0xb7eea000)
    libc.so.6 =>/lib/libc.so.6 (0xb7dd0000)
    /lib/ld-linux.so.2 (0xb7feb000)

What happened here? Remember what I said earlier about not loading any C + + code dynamically? Since we are still linking dynamically to libstdc++, the runtime support code in LIBGCC must the also is linked. g++ ignored THE-STATIC-LIBGCC flag because linking LIBGCC statically would not to result in a, program, and works properly. We need to link statically to both libraries, or neither.

Can ask g++ to tell your exactly what steps are involved in linking a C + + program (try The-v flag if you are curious) and invoke a slightly different set of commands in order to link your application with static versions of Libstdc++ and Li BGCC. But integrating that into your own build process are painful, error-prone, and specific to the machine and compiler version Use.

There ' s no-static-libstdc++ option to go along WITH-STATIC-LIBGCC, but you can let the compiler tell your path to the Static Libstdc++ Library It would use, and let g++look for libraries in a directory where it'll only find the static ve Rsion (in the case we build directory):

Ln-s ' g++-print-file-name=libstdc++.a '

g++-static-libgcc-l.-o example example.cpp ldd
    Linux-gate.so.1 =>  (0xffffe000)
    libm.so.6 =>/lib/libm.so.6 (0xb7ef3000)
    libc.so.6 => Libc.so.6 (0xb7dd0000)
    /lib/ld-linux.so.2 (0xb7feb000)

Once again, for this to work reliably you must don't use dynamically loaded C + + code, including code loaded with DL Open. In particular, statically linking the runtime support code are contraindicated when creating dynamically loadable C + + libra Ries. Depending on your linker it might being possible, but planning to distribute such the IS binaries still Super-sized can of worms.

Update: As of GCC 4.5 there is now a-static-libstdc++ compiler option which does what your ' d expect it to do. (to the Tim Hutt for pointing this.)