Launching an Application

When you launch an application from the Finder or the Dock, or when you run a program in a shell, the system ultimately calls two functions on your behalf, fork and execve. The fork function creates a process; the execve function loads and executes the program. There are several variant exec functions, such as execl, execv, and exect, each providing a slightly different way of passing arguments and environment variables to the program. In OS X, each of these other exec routines eventually calls the kernel routine execve.

When writing a Mac app, you should use the Launch Services framework to launch other applications. Launch Services understands application packages, and you can use it to open both applications and documents. The Finder and the Dock use Launch Services to maintain the database of mappings from document types to the applications that can open them. Cocoa applications can use the class NSWorkspace to launch applications and documents; NSWorkspace itself uses Launch Services. Launch Services ultimately calls fork and execve to do the actual work of creating and executing the new process. For more information on Launch Services, see Launch Services Programming Guide.

Forking and Executing the Process

To create a process using BSD system calls, your process must call the fork system call. The fork call creates a logical copy of your process, then returns the ID of the new process to your process. Both the original process and the new process continue executing from the call to fork; the only difference is that fork returns the ID of the new process to the original process and zero to the new process. (The fork function returns -1 to the original process and sets errno to a specific error value if the new process could not be created.)

To run a different executable, your process must call the execve system call with a pathname specifying the location of the alternate executable. The execve call replaces the program currently in memory with a different executable file.

A Mach-O executable file contains a header consisting of a set of load commands. For programs that use shared libraries or frameworks, one of these commands specifies the location of the linker to be used to load the program. If you use Xcode, this is always /usr/lib/dyld, the standard OS X dynamic linker.

When you call the execve routine, the kernel first loads the specified program file and examines the mach_header structure at the start of the file. The kernel verifies that the file appear to be a valid Mach-O file and interprets the load commands stored in the header. The kernel then loads the dynamic linker specified by the load commands into memory and executes the dynamic linker on the program file.

The dynamic linker loads all the shared libraries that the main program links against (the dependent libraries) and binds enough of the symbols to start the program. It then calls the entry point function. At build time, the static linker adds the standard entry point function to the main executable file from the object file /usr/lib/crt1.o. This function sets up the runtime environment state for the kernel and calls static initializers for C++ objects, initializes the Objective-C runtime, and then calls the program’s main function.

Finding Imported Symbols

When the dynamic linker loads a Mach-O file (which, for the purposes of this section, is called the client program), it connects the file’s imported symbols to their definitions in a shared library or framework. This section describes the process of binding the imported symbols in one Mach-O file to their definitions in other Mach-O files. It also explains the process of finding a symbol. See also Loading Plug-in Code With Bundles in Loading Code at Runtime for information on finding symbols in plug-ins.

ld -o my_tool -flat_namespace -undefined suppress peace.o love.o

Scope and Treatment of Symbol Definitions

Symbols in an object file may exist at several levels of scope. This section describes each of the possible scopes that a symbol may be defined at, and provides samples of C code used to create each symbol type. These samples work with the standard developer tools; a third party tool set may have different conventions.

A defined external symbol is any symbol defined in the current object file, including functions and data. The following C code defines external symbols:

int x = 0;

double y = 99 __attribute__((visibility("default")));   // GCC 4.0 only

An undefined external symbol is any symbol defined in a file outside of the current file. The following C code defines two external symbols, a variable and a function:

extern int x;

extern void SomeFunction(void);

A common symbol is a symbol that may appear in multiple intermediate object files. The static linker permits multiple common symbol definitions with the same name in input files, and copies the one with the largest size to the final product. If there is another symbol with the same name as a common symbol, the static linker ignores the common symbol instead.

The standard C compiler generates a common symbol when it sees a tentative definition—a global variable that has no initializer and is not marked extern. The following line is an example of a tentative definition:

int x;

A multi-module shared library, which ld builds by default, cannot have common symbols. However, you can build a shared library as a single module with the -single_module flag. To eliminate common symbols in an existing shared library, you must either explicitly define the symbol (with an initialized value, for example) in one of the modules in the shared library, or pass the -fno-common flag to the compiler.

A private defined symbol is a symbol that is not visible to other modules. The following C code defines a private symbol:

static int x;

A private external symbol is a defined external symbol that is visible only to other modules within the same object file as the module that contains it. The standard static linker changes private external symbols into private defined symbols unless you specify otherwise (using the -keep_private_externs flag).

You can mark a symbol as private external by using the __private_extern__ keyword (which works only in C) or the visibility("hidden") attribute (which works both in C and C++ with GCC 4.0), as in this example:

__private_extern__ int x = 0;                       // C only

int y = 99 __attribute__((visibility("hidden")));   // C and C++, GCC 4.0 only

A coalesced symbol is a symbol that may be defined in multiple object files but that the static linker generates only one copy of in the output file. This can save a lot of memory with certain C++ language features that the compiler must generate for each individual object file, such as virtual function tables, runtime type information (RTTI), and C++ template instantiations. The compiler determines which constructs should be coalesced; no work on your part is required.

A weak reference is an undefined external symbol that need not be found in order for the client program to successfully link. If the symbol does not exist, the dynamic linker sets the address of the symbol to zero. Files with weak references can be used only in OS X v10.2 and later. The following C code demonstrates conditionalizing an API call using a weak reference:

/* Only call this API if it exists */

if ( SomeNewFunction != NULL )

        SomeNewFunction();

To specify that a function should be treated as a weak reference, use the weak_import attribute on a function prototype, as demonstrated by the following code:

void SomeNewFunction(void) __attribute__((weak_import));

A coalesced weak reference is an undefined external reference to a symbol defined in multiple object files. In OS X v10.4 and later (with GCC 4.0 and later), you can specify that a symbol be made into a coalesced weak reference by adding the weak attribute to the symbol’s declaration. For example:

void SomeNewFunction(void) __attribute__((weak));

A weak definition is a symbol that is ignored by the linker if an otherwise identical but nowness definition exists. This is used by the standard C++ compiler to support C++ template instantiations. The compiler marks implicit—and not explicit—template instantiations as weak definitions. The static linker then prefers any explicit template instantiation to an implicit one for the same symbol, which provides correct C++ linking semantics. As with coalesced symbols, the compiler determines the constructs that require the weak definitions feature; no work on your part is required.

A debugging symbol is a symbol generated by the compiler that allows the debugger to map from addresses in machine code to locations in source code. The standard compilers generate debugging symbols using either the Stabs format or the DWARF format (supported in Xcode 2.4 and later). When using the Stabs format, debugging symbols, like other symbols, are stored in the symbol table (see OS X ABI Mach-O File Format Reference). But with the DWARF format, debugging symbols are stored in a specialized segment: the __DWARF segment. With DWARF you also have the option of storing debugging symbols in a separate debug-information file, which reduces the size of the binary files while permitting a full debugging experience when the corresponding debug-information files are available.