Anyone getting any wierd issues with Xcode 2.3?

[scratt]

Hay Guys!

I am having real problems getting some of my code to Link properly with the new Xcode...

It used to be fine with 2.2, and initially still builds fine with 2.3, but I am getting undefined labels which are expected in frameworks like Core Services and the like. This is the moment it gets to the linking stage..

I have tried various settings, and using different SDKs, but no joy.

Sometimes this can be because of a missed bracket or something in the source, or some other obscure error on my part. But I have gone back and used a backup which worked with 2.2 and get the same errors with 2.3.

Has anyone got a good source for trying to eliminate these problems, or any guesses (ANY!) as to what might be going on.. I have very little hair left this morning!

[funduk]

Have you figured it out? I've actually had problems similar to this with almost every version of Xcode I've used. Often you just need to Clean All...

If you did get it, post your solution so I can keep it on file for next time :p

[scratt]

Hi funduk,

Nope. Tried all the things you mention.

I have gone off on a tangent to work on something else.. Networking!

When I come back to the original project I expect the problem to have gone away, or to see the problem clearly with a fresh set of eyes...

I will post here with my findings then.

[scratt]

These are the linking errors I get..

/usr/bin/ld: Undefined symbols:
_CGRectCreate referenced from AppKit expected to be defined in ApplicationServices
_CoreDockCancelNotification referenced from AppKit expected to be defined in ApplicationServices
_CoreDockNotify referenced from AppKit expected to be defined in ApplicationServices
_CoreDockRegisterClient referenced from AppKit expected to be defined in ApplicationServices
_CoreDockWaitForTransitions referenced from AppKit expected to be defined in ApplicationServices
_CFReadStreamCreateWithFTPRequest referenced from Foundation expected to be defined in CFNetwork
_kCFStreamPropertyFTPProxyServerName referenced from Foundation expected to be defined in CFNetwork
_kCFStreamPropertyFTPProxyServerPortNumber referenced from Foundation expected to be defined in CFNetwork
_CFLocaleCreateCanonicalLanguageIdentifierFromStri ng referenced from CarbonCore expected to be defined in CoreFoundation
_CFLocaleCreateCanonicalLocaleIdentifierFromScript ManagerCodes referenced from CarbonCore expected to be defined in CoreFoundation
_CFLocaleCreateCanonicalLocaleIdentifierFromString referenced from CarbonCore expected to be defined in CoreFoundation
_CFLocaleCreateComponentsFromLocaleIdentifier referenced from CarbonCore expected to be defined in CoreFoundation
_CFNotificationCenterPostNotificationWithOptions referenced from CarbonCore expected to be defined in CoreFoundation


As you can see they are not from my source as far as Xcode is concerned...

But equally obviously anything could cause them (I guess) if I have some bizarro problem in my own source.. But I am at a loss to find anything.

Any bright ideas to track this OTHER THAN GOING THROUGH EVERY LINE OF EVERY FILE!

[bassplayinMacFiend]

Are you sure one of your #import statements isn't borked? Is there anything in the help docs related to CoreFoundation / AppKit?

I have yet to do any programming since I upgraded to 2.3, but when I do I'll report back in this thread.

[Enki]

This isn't a 2.3 speific issue, but I did have a similar problem under 2.2 where it just wouldnt link a C++ tool against the standard libraries to save my life. I reinstalled Xcode and then everything was magically OK. Remained OK through the update as well. I'm not overly thrilled with reinstall solutions, but at least reinstalling Xcode is nowhere as invasive as reinstalling an OS.

[scratt]

Enki, I will give that a try, but I am getting it on two machines now... So I am guessing that it is something in my source...

bassplayinMacFiend, I only have a couple of #imports going on.. The rest are #includes. I will go and check that today also...

Ha Ha!! Help Docs! Ha Ha! The Developer Documentation I have decided is a bit of a joke in many ways.. :)

[bassplayinMacFiend]

Unfortunately, Apple's documentation is quite lacking. Especially when compared to MSDN and the rest of MS offerings. :(

Maybe try changing your #includes to #imports?

[funduk]

"Maybe try changing your #includes to #imports?"

I would definitely do this as #import is just #include except better :p

Past that, archive your whole project and post it, might be able to help if we can actually see it.

[bassplayinMacFiend]

I would definitely do this as #import is just #include except better :p


I can't tell if you're being lighthearted or not with your post, but I do know I read somewhere in what little developer docs exist that #import is preferred over #include. I know that early in my Obj-C programming I ran into issues that disappeared when I switched to #import. Besides, all the new languages are doing it. :p

[Enki]

I can't tell if you're being lighthearted or not with your post, but I do know I read somewhere in what little developer docs exist that #import is preferred over #include. I know that early in my Obj-C programming I ran into issues that disappeared when I switched to #import. Besides, all the new languages are doing it. :p

#import and #include are fundamentally the same but different. The overly short version is #include is simply generates a text appendage to the top of your file during preprocessing, essentially pasting the contents of the header file into your calling file so the compiler can properly identify the referenced symbols. #import generally does this plus plays some namespace type games within the symbol tables and automagically handles multiple imports of the same file without the header file requiring the #ifndef #define #endif statements as helpers.

There are religious arguments over whether #import should be banished from all languages or not because some old-schoolers think anything automagic isn't painful enough. Currently the banishers seem to be losing.

[bassplayinMacFiend]

The feature of not requiring the #ifndef ... #endif is probably why they're preferred then.

If people want pain they can try and emulate a 3 button mouse in Linux on a Mac laptop.

[scratt]

I went another route... Thanks for all the input...

I took my files and my modifications to the core project I am basing this on, and then diff'd it with the latest revision of that same core project.

In one blinding move I updated the underlying system my sim relies on so that it was a couple of revisions further on by pulling the latest version from CVS, and then integrated the hooks that tie my derived classes and extra stuff into it.

I am working through a few small issues with the update now, but at least the damn thing compiles again, and I am now using a much more up to date set of files!

[funduk]

"I can't tell if you're being lighthearted or not with your post, but I do know I read somewhere in what little developer docs exist that #import is preferred over #include."

...? Sorry I'm confused now... I was saying use #import instead of #include because it's better and there's no real reason to use #include since it's essentially the same except does the 'magic' of not including files more than once etc... as mentioned above it saves you all the #ifndef garbage.

Maybe I just wasn't clear enough. I wasn't being lighthearted... I saying use #import instead of #include always. I think we're on the same page tho, so, whatever... :)