Thanks very much for the quick reply. It looks like the code
generation option "symbols hidden by default" is the one that needs to
be turned off. I was looking under "stripping" before.
After turning that setting off, 'nm -m' reports
00001f9c (__TEXT,__text) external _SomeFunction
instead of
00001f9c (__TEXT,__text) non-external (was a private external) _SomeFunction
and linking succeeds ...
On Sun, Feb 15, 2009 at 6:50 PM, Greg Parker <gpar...@apple.com> wrote:
>
> 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
>
>
--
http://www.mildmanneredindustries.com/
_______________________________________________
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
