New "Feature"? Was: Since Xcode 3.0, ld insists on linking...Resolved
New "Feature"? Was: Since Xcode 3.0, ld insists on linking...Resolved
- Subject: New "Feature"? Was: Since Xcode 3.0, ld insists on linking...Resolved
- From: Jerry Krinock <email@hidden>
- Date: Thu, 6 Dec 2007 20:45:05 -0800
OK, I finally found the problem which caused the Load command for
CoreData.framework to appear in my executable. In one of my source
code files, I invoke +[NSPersistentStoreCoordinator
metadataForPersistentStoreWithURL:error:]. The
NSPersistentStoreCoordinator class is defined in CoreData.framework.
So that brings me back to my previous question... I always thought
that if you call a function which is not defined in your project, you
get a linker error or a runtime crash. But, at least with this Apple
framework, you don't. Apparently, Xcode 3.0 is "smart" enough to think:
"Hey, that class you want there is defined in CoreData.framework.
It's an Apple framework that I know about. Looks like you forgot to
add it to your project, so I'd better slip in a little command to load
it during launch, just in case you don't load it programatically. Oh,
and since most people don't use Panther any more I won't bother you
with a warning."
Now, according to otool, a previous version of this same project,
which I built 10 days ago in Xcode 2.5, did not have that command
slipped in like that. I suspect that it compiled because, although
CoreData.framework did not have target membership, it was "in" the
project. The product ran fine, on 10.3-10.5, because, per my design,
that NSPersistentStoreCoordinator invocation did not run until after
the user had clicked on a Tiger-or-later feature which had caused the
app to programatically load my Tiger/Leopard bundle and thus load
CoreData.framework.
I'd be interested if someone could give a name for, and/or explain the
theory behind this new "smart loading". (But after spending the
better part of a day tracking this down, I will have a hard time
believing that "it's a feature".)
Jerry Krinock
P.S. After I fixed that problem, I found another problem that also
popped up with Xcode 3. I had written this code:
if (NSClassFromString(@"NSTokenField")) {
...
textTags = [[NSTokenField alloc] initWithFrame:frame] ; // bad
...
}
which is bad because, during a Panther launch, dyld will attempt to
link to the NSTokenField class "expected to be defined in AppKit",
find that it is not, and quit. Indeed, this is what happens after
building in Xcode 3.0. But when I built this in Xcode 2.5 it ran just
fine. (Rather than the Xcode upgrade, the cause in this case may have
been that I added/deleted or changed Target membership status of the
AppKit or Cocoa framework. I'm not sure.)
P.P.S. Just for for the sake of not leaving bad code dangling in the
list archives, here's the fix:
Class NSTokenFieldClass = NSClassFromString(@"NSTokenField") ;
// Above will be nil in Panther
if (NSTokenFieldClass) {
...
textTags = [[NSTokenFieldClass alloc] initWithFrame:frame] ;
...
}
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden