Static Linking for C++ Shared Objects


Assuming recent-vintage linux with standard C/C++ developer setup, including g++, readelf, ld, gold etc., etc. Reference platform is Fedora 17 (F17) using gcc-4.7.2. Linking static libraries may require the installation of non-default packages. For C/C++, this means:

yum install -y glibc-static libstdc++-static

Problem Description

Create a shared library that uses C++ internally, but with an external C interface and all dependent libraries statically-linked.

Some quick background/primer on creating a shared library with current GNU tools on recent linux. Consider the default case, making a shared library.

Take the first source file, a generic library function implemented in C++ and exported via extern C.

// filename:
#include <iostream>
#include <string>

extern "C" void announce()
  const std::string s("oooohllalala");
  std::cout << s << std::endl;

And then the second file, which uses it.

// filename:
extern "C" void announce();

int main()
  return 0;

Compile via:

g++ -shared -fPIC -O2 -g -o

g++ -g -O2 -L. -lannounce -o 28811.exe

To run the executable, first make sure that LD_RUN_PATH has the directory containing the shared library Then:


Which should print:


Now that that is confirmed to be working, here’s a closer look at the library file that was produced.

A look at the linked dependencies:

%ldd =>  (0x00007fffed1ff000) => /mnt/share/bld/gcc.git-trunk/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ (0x00007fd87e7e5000) => /lib64/ (0x00007fd87e4c3000) => /mnt/share/bld/gcc.git-trunk/gcc/ (0x00007fd87e4ad000) => /lib64/ (0x00007fd87e0f6000)
	/lib64/ (0x0000003b72200000)

This shows that the support library has a depedent link on the C language runtime (ie and, the GNU C/C++ language support libray (, the C++ language runtime (, and the linux dynamic loader (

A look at what’s in the library:

readelf -s | grep announce
    25: 0000000000000d20   226 FUNC    GLOBAL DEFAULT   11 announce
    61: 0000000000000d20   226 FUNC    GLOBAL DEFAULT   11 announce

This is our baseline setup. Now, try some variations.

The first variation: try with statically-linked.

g++ -shared -static-libgcc -fPIC -O2 -g -o

And then look at the library produced:

%ldd =>  (0x00007fff075ff000) => /lib64/ (0x00007f27ceeb9000) => /lib64/ (0x00007f27cebbd000) => /lib64/ (0x00007f27ce806000)
	/lib64/ (0x0000003b72200000) => /mnt/share/bld/gcc.git-trunk/gcc/ (0x00007f27ce7f0000)

It’s missing, as expected.

The second variation: try with and statically-linked.


g++ -shared -static-libgcc -static-libstdc++ -fPIC -O2 -g -o


%ldd =>  (0x00007fff819ff000) => /lib64/ (0x00007fdba493a000) => /lib64/ (0x00007fdba4582000)
	/lib64/ (0x0000003b72200000)

As expected.

Let’s try a third variation, to try for an all-C static link too. Ie:

g++ -shared -static-libgcc -static-libstdc++ -fPIC -O2 -g -Wl,-Bstatic -lc -lm -o

This doesn’t work:

g++ -shared -static-libgcc -static-libstdc++ -fPIC -O2 -g -Wl, -static -lc -lm -o
/usr/bin/ld: /mnt/share/bin/H-x86_64-gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/mnt/share/bin/H-x86_64-gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbeginT.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status

Known Bugs


Older bugs:


Some of these bugs are many years old, and the build machinery has changed since they were first filed.

Basics on impacted sources:


and configure via PIC_CXXFLAGS


testing via

     [list "incdir=$srcdir" "additional_flags=-w -shared 
     { dg-options "-static-libstdc++ -std=gnu++11" }
     { dg-options "-shared -fPIC -static-libgcc -static-libstdc++"

It looks like the C++ compiler testsuite has a bunch of -fPIC tests, some -fPIC -fvisibility=hidden tests (mostly in the context of local statics), and some -static tests.


1) Are these expectations valid for C too?

First, what the GCC Manual says about the specific link options. Use “N1975 Dynamic Shared Objects: Survey and Issues” as background.

Then figure out the uses for:

  • -static
  • partial static shorcuts: -static-libgccgcc, -static-libstdc++
  • partial static via:
    -Wl,-static -lssl -lcrypto

2) how to check to see if an object has relocations

readelf -r foo.o

Ian Taylor has a nice description of relocations.

Template-fu, Zen Linking

Welcome, weary traveller.

Please, enter the dojo. Have some tea. Sit, and listen to me expound on the state of linking today.

There are a number of new techniques for linking in C+11. Some are not widely known. Some require long nights, on cold drafty mountain tops to fully master.

The new forms:

1. Extern Template

When you want white. Nothing. A truly private implementation, with only the API exported. Use extern template on class specializations to tell the compiler to not implicitly instantiate any symbols when the class is used by user code. For template functions as well.

Smartly done on forward-declarations, after the main class has been defined, making them post-declarations.  Pretty much anything goes: the syntax is the same as the syntax for explicit instantiations. Precisely because the two are a matched pair: with the power to prohibit instantiations comes the responsibility to explicitly instantiate them in some form. Wax on, wax off.

With C++11, extern template is portable. GNU C++ users have used it widely since 2002.

2. -fvisibility=hidden

And why it’s different from extern template. There seems to be a lot of confusion out there, about this. And let’s face it, the syntax is atrocious! Absolutely abominable.

GNU extensions, apply as attribute on namespaces.

3. constexpr


4. Namespace association. Tarsier-style.

But I will not bore you, weary traveller. Sit and enjoy your beverage. There will be plenty of time to talk about new techniques and methods later, after you have rested from your voyage.