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.
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 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.