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.