On Feb 15, 2009, at 10:32 AM, Martin Redington wrote:
In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
"direct" access to any internal object data, as C functions, like the
simple example below.
@implementation FunctionTestAppController
+ (id) sharedController
{
return [NSApp delegate];
}
- (BOOL) someMethod
{
// would normally access some ivar.
return YES;
}
@end
BOOL SomeFunction()
{
return YES;
}
I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.
Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.
Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?
What does `nm -m` say? It's likely that your C function's symbol is
present but marked non-external, which means it's available for
debuggers but not for linking. (`nm` alone provides a single-letter
description of the symbol, and `nm -m` prints the description in human-
readable form.)
If that's the case, you can change your executable's symbol management
in Xcode. I think the options are to provided an exported-symbol list
that names the C functions explicitly, or change the stripping level
to none so they're all available. You should do this only for testing
purposes and not for your final release configuration; keeping symbols
hidde makes your app launch a little faster.
(The Objective-C code probably works because the C linker is mostly
not used for 32-bit Objective-C linking. But it's likely that a 64-bit
version of your app would run into the same problem for Objective-C
code.)
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
