Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

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)
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2006-03-30 @970 Last change: 2014-07-28 @386 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.