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 foo.cc -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.
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,-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 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.
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.