When you create Carbon applications in CodeWarrior, you can link against MSL C and C++ libraries (in debug and nodebug variants) to create CFM-style executables that can run in Mac OS 9 or Mac OS X. There is no system-supplied C library in Mac OS 9, so your application relies on the development environment, which for CodeWarrior, means the MSL libraries.
In Mac OS X, there are system-supplied C and C++ libraries. The C library comes in static and dynamic variants. The dynamic version is strongly recommended for most software, though you may need to link the static version in certain situations (such as for KEXTs, which must load when the dynamic loader isn’t available).
Beginning with Mac OS X 10.3.9, the standard C++ library is packaged as a dynamic shared library. In prior versions of Mac OS X, the C++ library is packaged as a static library. Packaging the standard C++ library as a dynamic shared library provides a number of benefits, such as smaller binaries and improved performance. To link against the shared library version, libstdc++.dylib, you must use GCC 4.0. If your application must run on versions of Mac OS X prior to 10.3.9, however, you must link against the static library, libstdc++.a . To learn more about the C++ runtime and using the shared library version of libstdc++ , see C++ Runtime Environment Programming Guide.
CodeWarrior also supplies MSL libraries to create Mach-O style executables that run on Mac OS X only. In some cases, the MSL library calls through to the Mac OS X System framework library, and in some cases it provides missing features (such as wchar_t support, not available in Mac OS X prior to Panther).
If your CodeWarrior project is already building a Mach-O style executable, you should have an easier time in moving it to Xcode. If not, you should consider converting it, as described in “Preparing a CodeWarrior Project for Importing.” You’ll primarily be changing linker settings, access paths, and precompiled headers. In addition, if you load plug-ins via CFM, you’ll need to rewrite that code to use the CFBundle or CFPlugin APIs.
Important: Static libraries currently will not be linked in Xcode unless they are named according to the format lib*.a. That is, they must start with lib and have the extension .a.
For related information, see “The GCC Compiler.”
The following are some runtime and library issues you may encounter in switching from MSL libraries to the Mac OS X C and C++ libraries:
There is no runtime support for wchar_t and wstring prior to Mac OS X version 10.3 (Panther). For details, see “Support for wchar_t and wstring.”
While CodeWarrior supplies nonstandard flags to perform diagnostics on use of the standard template library (STL), Xcode does not include a debug version of the STL.
Some code will be larger when built with the Xcode standard C and C++ libraries because, unlike the MSL library, they do not currently support container optimization for templates.
The standard C library function clock (or ctime for C++) returns a value of type clock_t in units of CLOCKS_PER_SEC, defined in time.h. This constant currently has a value of 100, which results in a low resolution that is inadequate for some tasks. CodeWarrior defines CLOCKS_PER_SEC as 1000000, for microsecond resolution.
The function itoa is not a standard C library function and it is not included in the system libraries provided by Mac OS X. CodeWarrior does supply this function, in the header extras.h. If your code uses this function, you should replace it with printf or some other equivalent function.
Last updated: 2006-10-26