Deploying Applications With the C++ Runtime

In most situations, you should never have to worry about linking against the C++ runtime environment. When you build your C++ code, GCC chooses the most appropriate version of the C++ standard library and links to it. For applications compiled using GCC 3.3, the compiler links to the static C++ standard library libstdc++.a. For applications compiled using GCC 4.0, the compiler links to the dynamic C++ standard library libstdc++.dylib by default (libstdc++.a is also available as an option).

The following sections describe issues you may encounter when linking against the dynamic runtime or the new static runtime. There are no known issues worth noting for deploying code using the original static C++ runtime.

Caveats for Using the New C++ Runtimes

The following caveats apply to the new static and dynamic C++ runtimes.

Deploying With the New Dynamic Runtime

This is the library used by default when using GCC 4.0 and is appropriate when targeting OS X v10.3.9 and later. For a list of caveats for using this library, see Caveats for Using the New C++ Runtimes.

Deploying With the New Static Runtime

In Xcode 2.3, a new version of the static C++ standard library libstdc++-static.a was introduced. You can link against the new static C++ standard library using Xcode 2.3 or the command line. To link against the library using Xcode, simply set "C++ Standard Library Type" in the build settings to "Static". To link against this library on the command line, use gcc instead of g++ and append the following two commands to the end of the command: -shared-libgcc and -lstdc++-static. For example:

gcc one.o two.o -o my_application -shared-libgcc -lstdc++-static

For a list of caveats for using this library, see Caveats for Using the New C++ Runtimes and the next section.

Additional Caveats for Using the New Static Runtime

The new static C++ standard library marks all of its symbols as "hidden", which means those symbols are not exported by an application that links to the library. It is still possible, however, for symbols from the C++ library to be exported by your application. For example, your application might include symbols from the library in header files or other visible locations. To prevent symbols from being accidentally exported, you must use an export list for any binaries that link against the static C++ library. (For more information about the use of export lists, see Reducing the Number of Exported Symbols. For information on using visibility pragmas and visibility switches to control symbol visibility in your own code, see Controlling Symbol Visibility.)

Callback functions (such as registered with std::set_terminate) are only effective when triggered within the same code module.

This static library has the same size disadvantages as the one used with gcc 3.3. For details about this issue, see Advantages of a Shared C++ Runtime .