Keywords: ISO C++, library

Linking
Prev | Chapter 3. Using | Next

## Linking

### Almost Nothing

Or as close as it gets: freestanding. This is a minimal configuration, with only partial support for the standard library. Assume only the following header files can be used:

- `cstdarg`

- `cstddef`

- `cstdlib`

- `exception`

- `limits`

- `new`

- `exception`

- `typeinfo`

In addition, throw in

- `cxxabi.h`.

In the C++11 dialect add

- `initializer_list`

- `type_traits`

There exists a library that offers runtime support for just these headers, and it is called `libsupc++.a`. To use it, compile with gcc instead of g++, like so:

gcc foo.cc -lsupc++

No attempt is made to verify that only the minimal subset identified above is actually used at compile time. Violations are diagnosed as undefined symbols at link time.

### Finding Dynamic or Shared Libraries

If the only library built is the static library (`libstdc++.a`), or if specifying static linking, this section is can be skipped. But if building or using a shared library (`libstdc++.so`), then additional location information will need to be provided.

But how?

A quick read of the relevant part of the GCC manual, Compiling C++ Programs, specifies linking against a C++ library. More details from the GCC FAQ, which states GCC does not, by default, specify a location so that the dynamic linker can find dynamic libraries at runtime.

Users will have to provide this information.

Methods vary for different platforms and different styles, and are printed to the screen during installation. To summarize:

- At runtime set `LD_LIBRARY_PATH` in your environment correctly, so that the shared library for libstdc++ can be found and loaded. Be certain that you understand all of the other implications and behavior of `LD_LIBRARY_PATH` first.

- Compile the path to find the library at runtime into the program. This can be done by passing certain options to g++, which will in turn pass them on to the linker. The exact format of the options is dependent on which linker you use:

  - GNU ld (default on GNU/Linux): `-Wl,-rpath,` `destdir/lib`

  - Solaris ld: `-Wl,-R` `destdir/lib`

- Some linkers allow you to specify the path to the library by setting `LD_RUN_PATH` in your environment when linking.

- On some platforms the system administrator can configure the dynamic linker to always look for libraries in `destdir/lib`, for example by using the ldconfig utility on GNU/Linux or the crle utility on Solaris. This is a system-wide change which can make the system unusable so if you are unsure then use one of the other methods described above.

Use the ldd utility on the linked executable to show which `libstdc++.so` library the system will get at runtime.

A `libstdc++.la` file is also installed, for use with Libtool. If you use Libtool to create your executables, these details are taken care of for you.

### Experimental Library Extensions

GCC 5.3 includes an implementation of the Filesystem library defined by the technical specification ISO/IEC TS 18822:2015. Because this is an experimental library extension, not part of the C++ standard, it is implemented in a separate library, `libstdc++fs.a`, and there is no shared library for it. To use the library you should include `<experimental/filesystem>` and link with `-lstdc++fs`. The library implementation is incomplete on non-POSIX platforms, specifically Windows support is rudimentary.

Due to the experimental nature of the Filesystem library the usual guarantees about ABI stability and backwards compatibility do not apply to it. There is no guarantee that the components in any `<experimental/xxx>` header will remain compatible between different GCC releases.

Prev | Up | Next
Namespaces | Home | Concurrency