The Dangers of ZeroLink

"ZeroLink can make unlinked functions half-work. That's a thing to keep in mind..." Apple's Xcode IDE offers a facility called ZeroLink (and it's on by default). ZeroLink essentially means that instead of fully linking an application when it is built, it performs the linking at runtime as needed. This has advantages like not needing to re-link the entire application when you make a small change to one file and run it to test that aspect.

Especially on slow machines it provides a noticeable speed-up, and it also allows for nifty features like "Fix and Continue" where it recompiles a few changed source files and swaps them into the application while you're debugging it, effectively giving you the flexibility of a prototype-based or interpreted language when it comes to debugging or simply experimentally figuring something out.

With all these advantages, it has one disadvantage: It does not link your application at compile-time. While that may not sound like much of a problem considering it dynamically links at runtime, it can become apparent after some use. ZeroLink is inherently bound to the compiled object files on your machine, meaning you can't reliably move ZeroLinked applications to another computer. So, for deployment builds, Xcode wisely decides not to use ZeroLink.

So now you're developing and debugging your application under entirely different circumstances than it will be run. In particular, your application may get loaded partially, and then the system may pull in some additional libraries it needs, like the Carbon HIToolbox. If you forgot to link in this library, you'll still be able to access it since the OS happened to load it. As soon as you switch to a "deployment" build, however, you'll get lots of new linker errors.

That's obvious when you think about it afterwards, but if you just added a whole slew of code written by someone else or you're several people on one project, you may not even be aware that a particular library is being used. Also, for some odd reason, sometimes such an un-linked library may give spurious errors. I recently did code that uses AESend() and it kept returning odd errors on a perfectly valid call, just to work fine on the next call. I almost feared I had a memory bug somewhere.

After trying to track this down without success I thought I'd just test the rest of the app in a deployment build and return to that bug after a night's sleep. During building I noticed I'd forgotten to link in Carbon.framework. I added that, and haven't seen the spurious error ever since.

So, instead of just breaking or just working, ZeroLink can make unlinked functions half-work. That's a thing to keep in mind...

Reader Comments: (RSS Feed)

Amrita writes: Thanks, this info saved me a lot of trouble.

Alexandre writes: Each time I create a new XCode Project, I disable 'ZeroLink' and 'Fix & Continue' in the Debug settings. These settings caused me more troubles than they saved me time.

Uli Kusterer replies: ★ Alex, Fix & Continue is dependent on ZeroLink, so turning off that one setting should get you both.

Brian Ray writes: I turned zerolink off by default somehow. I can not recall how I did it, probably a similar script, but Mark suggests this: http://www.borkware.com/quickies/single?id=259 -- Brian Ray

Jean-Daniel Dupas writes: I bet AESend return -1700 error. I already encounter this problem, and i think that's because the coercion handlers are automatically installed by the Carbon Frameworks when it loads. And it does not occured if you do not include it in your build settings. I hope those problems are solved in Xcode 3.

M Gangadhar writes: Thanks for giving valueable message i am very much suffering from this one. now i solved linking the ABAddressBook framework. Thanks and Regards M.Gangadhar (India)

Or E-Mail Uli privately.