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

As of GCC 13, libstdc++ implements P1642, which brings in many more headers, as well a quite a few ones not covered by the paper. In general, if a feature does not require traditionally libc-provided facilities, or dynamic memory allocation, it's enabled in the freestanding subset. In addition, if only a subset of a header requires such features, it is partially included. Some examples include:

  • string_view

  • tuple

  • bitset

Currently, this subset includes all of the iterator APIs (including the ranges APIs) that do not involve streams, the entire C++ algorithms library, excluding parallel algorithms, and a large part of the utilities library. This is on top of the headers included in the lists above.

If you're using a libstdc++ configured for hosted environments, and would like to not involve the libraries libstdc++ would depend on in your programs, you will need to use gcc to link your application with only libsupc++.a, like so:

gcc -ffreestanding -lsupc++

If you configured libstdc++ with --disable-hosted-libstdcxx, however, you can use the normal g++ command to link, as this configuration provides a (nearly) empty libstdc++.a.

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 (, 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,-Rdestdir/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 library the system will get at runtime.

A 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 is only partially supported. Since GCC 14, libstdc++exp.a also contains the definitions for this library, so -lstdc++exp can be used instead of -lstdc++fs.

GCC 13 includes an implementation of the C++ Contracts library defined by P1429R3. Because this is an experimental extension, not part of the C++ standard, it is implemented in a separate library, libstdc++exp.a, and there is no shared library for it. To use the library you should include <experimental/contract> and link with -lstdc++exp.

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