Cosas que no puedo Olvidar II
Using ZeroLink
ZeroLink speeds application development time by eliminating the link process from development builds. Instead, Xcode generates an application stub that contains the full paths to the object files that make up the application. At runtime, each object (.o) file is linked as it’s needed. This works only when running your application within Xcode. You cannot deploy applications using ZeroLink.
To turn ZeroLink on or off, use the ZeroLink (ZERO_LINK) build setting. ZeroLink is enabled by default in the Debug build configuration. If you build with this build configuration, you automatically get ZeroLink functionality. See “Overview of Build Configurations” for more information on using build configurations; for a description of how to modify build settings, see “Editing Build Settings in the Xcode Application”. ZeroLink works only for native targets.
In the following sections you’ll learn how to customize ZeroLink to further reduce application launch times. You’ll also receive pointers to keep in mind when using ZeroLink.
In this section:
Customizing ZeroLink
Caveats When Using ZeroLink
Customizing ZeroLink
ZeroLink postpones the linking of object files until the last moment possible. However, there are some symbols that, by default, are always resolved (that is, the corresponding object files are linked against the application and the code is executed). These symbols are static initializers in C++ and +load methods and categories in Objective-C. You can tell ZeroLink not to search the object files of your application for these symbols to reduce the application’s launch time.
Sometimes objects must be initialized before a program’s main function is called. For example, a class may declare global variables that can be accessed by other code before the class has a chance to initialize them. In Objective-C, the +initialize method may be executed too late (see The Objective-C Programming Language). Static initializers (in C++) and +load methods (in Objective-C) provide developers with a mechanism to initialize variables at the earliest possible point during a program’s launch process. In Objective-C–based applications, categories are also loaded before main is called.
When you build an application, the static linker adds the standard entry-point function to the main executable file. Before calling main, this function sets up the runtime environment state for the kernel and the application, by calling static initializers (for C++ code) and loading categories and invoking +load methods (for Objective-C code).
When using ZeroLink, you can further reduce the launch time of the application by postponing the execution of static initializers and +load methods, and the loading of categories. But you must be certain that code in your application doesn’t rely on static initializers or +load methods being called before main or on categories being loaded before main is called. Otherwise, your application may crash or behave unexpectedly.
There are three linker options you can use to customize ZeroLink in your project. To use these options, add them to the Other Linker Flags (OTHER_LDFLAGS) build setting:
-no-run-initializers-before-main: If an application contains C++ code, the linker looks for static initializers at launch time before calling main in all the object files that make up the application and, if it finds any, links the object files containing them into the application. This may slow down application launch. If you’re developing an application using C++ and it doesn’t depend on static initializers being run before main, use this option to prevent ZeroLink from scanning object files in search of static initializers before calling main.
Keep in mind that if code requires that static initializers be run before main, your application could crash. This is especially true for applications that use static initializers to register code with a registry. If the sole purpose of the static initializers is to perform the registration (that is, if no other code would ever trigger the execution of the static initializers by accessing a global variable, for example), no registration would take place. For example, when reading a serialized file, the reader reads the name of the class of each serialized object and tells the class to reconstruct an instance from the data. In C++ there is no infrastructure to look up a class by name. Instead, a common idiom is for each class capable of serializing and deserializing instances of itself to register its class name and deserialization method address with the reader using a static initializer.
-no-load-categories-before-main: If an application contains Objective-C code, the linker looks for categories at launch time before calling main in all the object files that make up the application. If it finds any, it links the object files containing them into the application. As with -no-run-initializers-before-main, this may slow application launch. If your application doesn’t depend on categories, use this option to prevent ZeroLink from scanning object files in search of categories before calling main.
Some developers rely on the use of categories in the implementation of their class hierarchies. In such a model, the implementation of a class spans one or more categories of that class. Using this design model, a program may run incorrectly when the categories that implement additional class functionality are not loaded. With ZeroLink, classes can be loaded when needed because there’s a direct reference to them, but ZeroLink cannot load categories dynamically. Therefore, if your application depends on categories, it may crash or behave unexpectedly if you use the -no-load-categories-before-main flag.
-no-run-load-methods-before-main: As it does with -no-load-categories-before-main, ZeroLink scans object files for +load methods in Objective-C code before main is invoked to link them to the application. Using this option prevents the scanning of object files for +load methods before ZeroLink calls main. +load methods in Objective-C are similar to static initializers in C++: They are executed early during application launch, before main is called, to perform tasks that must be performed at the earliest possible time. However, the order of execution of +load methods is not guaranteed. If your code depends on +load methods to be run before main, your application may crash or run incorrectly if you use this flag.
When building an application that uses static libraries (.a files), each static library is linked to produce a bundle. At runtime, each bundle is loaded on demand. If your application starts slowly while using ZeroLink and has a large number (100 or more) of object files, you can try adding an intermediate static library target, one containing the relatively stable parts of your source code. This gives you the best of both worlds: static (build time) linking for stable code and dynamic (runtime) linking for code that changes frequently.
If you want to view information about the loading and linking of object files as your application runs, set the ZERO_LINK_VERBOSE environment variable, in the target’s executable, to any value. The information appears in the run log of the application or stderr.
Caveats When Using ZeroLink
These are some things you should keep in mind when using ZeroLink:
ZeroLink doesn’t support the use of private external symbols, that is, symbols declared as __private_extern__.
Private external symbols are visible only to other modules within the same Mach-O file as the modules that contain them. If you use a private external symbol in your project while ZeroLink is turned on, you get an unknown-symbol error when your code tries to access it. For example, if you have the definition __private_extern__ int my_extern = 800; in a source file and the declaration extern int my_extern; in another source file, when the second module accesses my_extern, your application exits with the following log output:
ZeroLink: unknown symbol ‘_my_extern’
MyApplication has exited due to signal 6 (SIGABRT)
For more information on private external symbols, see “Scope and Treatment of Symbol Definitions” in Executing Mach-O Files in Mac OS X ABI Mach-O File Format Reference.
When setting breakpoints on methods, you must use full method specifiers, not just selectors. For example, if your project has a class named MyClass with an instance method called myMethod, you must specify a breakpoint on myMethod like this:
-[MyClass myMethod]
Normally, using the breakfunctionName command from the gdb command-line to set breakpoints in a program prompts gdb to display the breakpoints menu when the specified function name is defined more than once. However, because not all .o files are loaded at launch when you are debugging an executable built with ZeroLink, gdb does not have access to all of the symbols in your program and thus cannot display all of the possible breakpoints for that function name. To set a breakpoint on a function from the command-line, use the fb command, as in the following example:
fb -[SKTRectangle makeNaturalSize]
Note that this approach requires knowing where the function or method you want to break on is defined. If you are using the debugger from within Xcode, Xcode maintains breakpoint information for your project and is responsible for telling the debugger where to break.
For more information on the breakpoints menu in GDB, see Breakpoint menus in Debugging with GDB. To learn more about the fb command, type help fb at the (gdb) prompt in the debugger console window of Xcode or in the Terminal application.
If you get an error similar to this one:
dyld: /Users/user_name/MyApp/build/MyApp.app/Contents/MacOS/MyApp Undefined symbols:
Foundation undefined reference to _objc_exception_set_functions expected to be defined in
/System/Library/PrivateFrameworks/ZeroLink.framework/Versions/A/Resources/libobjc.A.dylib
delete /System/Library/PrivateFrameworks/ZeroLink.framework/Versions/A/Resources/libobjc.A.dylib.
You would get this error if you install the Xcode tools in a system with a prerelease version of Mac OS X. The libobjc.A.dylib file contains a developmental copy of the Objective-C runtime environment. It’s not necessary for normal development.
Building with ZeroLink may hide undefined symbols. Although undefined symbols in a project normally results in link errors during a build, ZeroLink sidesteps the linking process. Running a development build built with ZeroLink enabled will only detect undefined symbols if that symbol is loaded. Since it is unlikely that running your executable will exercise every code path, you should try building without ZeroLink enabled regularly throughout the development process, to make sure that your code links properly.
Show TOC < Previous PageNext Page >
© 2004, 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-05-23)
Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.