This section discusses issues related to runtime support.
Compilers will automatically link with libgcc when necessary, but if something goes wrong, knowing what the library is designed to do can be helpful. The gcc support library (libgcc) has a variety of helper routines in the form of an archive library called libgcc.a and a shared library called libgcc_s.so. libgcc includes routines to support exceptions and routines to support integer and floating-point operations that might not have direct instructions for the current architecture. The functionality in the library is described in The GCC Low-level Runtime Library in the gcc documentation.
Executables created using the gcc compiler are linked against libgcc.a and will not have a dynamic dependency against libgcc_s.so. Executables created with the g++ compiler will use libgcc_s.so instead and will have a dynamic dependency on it.
Code produced by the Oracle Developer Studio C compiler does not have any dependencies on libgcc.
Code produced by the Oracle Developer Studio C++ compiler does not depend on libgcc when building in Sun mode (–compat=5), but will have such a dependency when building in GNU compatibility mode (–compat=g, –std=c++03, –std=c++11, or –std=c++14).
On Oracle Linux, a similar library named libc_supp.a is included with Oracle Developer Studio.
A source file compiled with the Oracle Developer Studio C++ compiler needs to be linked using the Oracle Developer Studio C++ compiler to make sure that the correct runtime libraries, CRT files, and linker options are used. g++ object files should be linked with g++. Because of the many incompatible implementation details used in object files, mixing object files from the Oracle Developer Studio C++ and g++compilers into the same executable or shared library is not supported.
Shared libraries created by Oracle Developer Studio C++ in GNU compatibility mode (with the options –compat=g, –std=c++03, –std=c++11, or –std=c++14) can be mixed with shared libraries created by the g++ compiler and linked into a main program created by either compiler, but they must use the same version of the g++ ABI.
When operating in GNU compatibility mode, the Oracle Developer Studio C++ compiler is binary compatible with g++ code in the area of library interfaces, name mangling, and the binary layout of standard library objects. But it still uses different mechanisms for many other underlying aspects of the implementation. External inline functions, template instances, RTTI records, and exception range information are implemented using COMDAT in a distinct way. Exception range information is formatted in a very Studio-specific way. This limits the amount of mixing you can do between object files and archive libraries compiled with Oracle Developer Studio C++ and those compiled with g++.
Due to an incompatible change in the GNU C++ ABI between versions 4.x and 5.x, executables and libraries compiled with g++ must use one ABI consistently to work correctly. The 5.x GNU C++ library supports both ABIs, but a compiler (GCC or Oracle Developer Studio) can generate only one ABI at a time. The g++ compiler defaults to the 5.x ABI. To select the 4.x ABI, compile with–D_GLIBCXX_USE_CXX11_ABI=0.
The Oracle Developer Studio 12.5 C++ compiler implements only the 4.x ABI. To mix shared libraries and executables, build the g++ parts with the above option. The g++ documentation for this issue is available at https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html.
Technically, there is nothing to stop a 4.x library or executable from being used alongside a 5.x library or executable, but they cannot call each other using library classes that are different in the two ABIs. Some of those classes are commonly used (like the string class), so you cannnot accomplish much by mixing the two ABIs.
The main function in C++ carries some extra mechanisms. Whichever compiler is used to compile the object file with main should also be used to link the executable. The crt object files used by the compiler driver will match the mechanism embedded in the object file main.
When compiling code in GNU mode, the Oracle Developer Studio C++ compiler uses the GNU C++ library, but it also needs to link an additional library called libCrunG3.so to supply support functions for RTTI, exceptions, and other language features. This library corresponds to the libCrun.so library that is used in Sun mode (–compat=5).
The Oracle Developer Studio 12.5 C++ compiler (in GNU compatibility mode) uses the 5.1.x version of the GNU C++ library. You can mix shared libraries and applications built with different versions of the GNU C++ library, but the compiler used to build and link the main application should be a version at least as recent as the compiler used to create any of the shared libraries. If any shared libraries are built with Oracle Developer Studio C++, the main application should be built either with Oracle Developer Studio C++ or with a g++ compiler that supports the 5.1.x GNU C++ library.
C++ runtime libraries are located in a variety of places.
The following Sun mode (–compat=5) C++ libraries are in /usr/lib on Oracle Solaris, but not on Oracle Linux:
libCstd.so
libCrun.so
libdemangle.so
libiostream.so
libstdcxx.so
The following GNU mode C++ libraries are in /usr/lib on Oracle Solaris, but not on Oracle Linux:
libCrunG3.so (but you may need a patch for Oracle Solaris package SUNWlibC)
libdemangle.so
All other C++ runtime libraries are in the compiler installation directory.
When the Oracle Developer Studio C++ compiler links against any shared libraries that are bundled with Oracle Developer Studio, it normally adds the necessary RPATH setting into the executable to find the libraries at runtime. You can prevent this behavior and configure the RPATH setting yourself by adding the –xnorunpath option and adding appropriate –R options.
Compiling source code with –xopenmp generates runtime dependencies on system libraries, which for the Oracle Developer Studio compilers is the libmtsk library. On Oracle Solaris, this library is available in /usr/lib. On Oracle Linux this library is in the compiler installation directory. Because thread management is a process-wide operation, use only one OpenMP implementation in a program. If a shared library uses OpenMP, the main application cannot use a different OpenMP implementation. The Oracle Developer Studio implementation of OpenMP is not compatible with the GCC implementation of OpenMP.
Atomics is a new language feature in the C 2011 and C++ 2011 standards that requires runtime support from the operating system. The Oracle Developer Studio compilers support this feature with a preliminary bundled runtime library that is compatible with some versions of GCC runtime libraries (see Bundled Atomics Library in Oracle Developer Studio 12.5: C++ User’s Guide), and you can use the –xatomic option to select which runtime library to use when linking your programs and libraries.
The GCC and Oracle Developer Studio compilers implement thread local data (__thread declarations) in a way that conforms to the OS ABI (Oracle Solaris or Oracle Linux) so functionality is compatible between code compiled by Oracle Developer Studio and GCC compilers. For more information about the Oracle Solaris ABI for thread local data, see the Oracle Solaris 11.3 Linkers and Libraries Guide.