Weird Objective-C observation
Weird Objective-C observation
- Subject: Weird Objective-C observation
- From: John Stiles <email@hidden>
- Date: Wed, 7 Sep 2005 10:39:57 -0700
I have had NDAlias in my codebase for quite a while. It works great,
no complaints :)
Recently we did a code reorganization and decided to put all of our
open-source outside code into one central CVS folder, and at the same
time we made a separate target for all this code. So, along with
other open-source blocks of code (Expat, Zlib, etc.), NDAlias moved
into a lib file ("libContrib.lib"). Our main project has a dependency
on this target. So far, so good. All the C-based code works great.
For some reason, though, this change broke NDAlias. It appears that
NDAlias adds categories on system classes, and these are no longer
getting installed when the app starts up. To make a long story short,
-getFSRef is one of many methods that's added to NSURL via a custom
category:
@interface NSURL (NDCarbonUtilities)
//...etc...
- (BOOL)getFSRef:(FSRef *)fsRef;
// ...etc...
@end
And as soon as NDAlias calls [someNSURLObject getFSRef], it crashes
in NSRaiseError:
*** -[NSURL getFSRef:]: selector not recognized [self = 0x536a5e0]
I'm sure the other functions added via categories break too, but this
is the crash we end up hitting first.
I couldn't figure out a way to make a lib file and still have it
retain its Objective-C functionality. As soon as I retarget the
NDAlias code to be built as part of the main project instead of the
lib, then clean and rebuild, this problem vanishes. So I have a
workable solution, but it seems a little hokey. Why is this happening?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden