Caveats for Using the New C++ Runtimes

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

• If your program must run on versions of OS X prior to 10.3.9, as well as OS X v10.3.9 and later, you must use the GCC 3.3 compiler and build your program using the original static C++ standard library (libstdc++.a).

• Applications that run on OS X v10.3.9 must not try to use the long double type or any of the functions associated with it. Support for the 128-bit long double type was not introduced until OS X v10.4. Similarly, full support for sinl, expl, and all other long double math functions defined by the C standard is available only in 10.4 and later.

• When overriding the new and delete operators, your overrides will be visible across shared library boundaries (application wide) unless you specifically takes steps to make them hidden (such as with an (un)export list). Even uses of new/delete in system frameworks, in the dynamic C++ runtime (even if you are only indirectly linked to it) or in other modules (possibly linked statically or dynamically to the C++ runtime) will use your overrides, unless that module also has overridden new/delete operators.

  Unless you are sure that code modules are using the same operator new and delete, do not transfer memory ownership across shared library boundaries.

• Multithreaded applications which use the standard stream (std::cin, std::cout, and so on) must explicitly synchronize their use of these global objects if there is any chance that two threads may simultaneously access one of them. Functions that set global state (such as set_terminate, set_unexpected, and so on) must also be explicitly synchronized if multiple threads can call them at once. In general:

  1. It is safe to simultaneously call const and non-const methods from different threads to distinct objects.

  2. It is safe to simultaneously call const methods, and methods otherwise guaranteed not to alter the state of an object (or invalidate outstanding references and iterators of a container) from different threads to the same object.

  3. It is not safe for different threads to simultaneously access the same object when at least one thread calls non-const methods, or methods that invalidate outstanding references or iterators to the object. The programmer is responsible for using thread synchronization primitives to avoid such situations.

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.