• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Stupid Linker Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stupid Linker Question


  • Subject: Re: Stupid Linker Question
  • From: Jim Ingham <email@hidden>
  • Date: Tue, 1 Feb 2005 11:12:09 -0800

It's best to link against the smallest set of frameworks that you can. The loader does have to do some (though not that much) work to bind the frameworks into your application. And some frameworks do still have initialization routines that will get run when they load, though the Mac OS X program team tries to keep this to a minimum. However, it isn't necessary to go hog-wild on removing unneeded frameworks. For the most part the common Application frameworks will already be loaded into shared memory by the other apps in the system, and your app will just use this copy. So the amount of work that is required by the loader is not all that much.

Note also that, in general, the subframeworks of a given framework CAN'T be independently linked against. Some frameworks are explicitly hidden beneath their umbrella framework, and if you try to link with them you will get an error:

inghji:/tmp > gcc -g -O0 main.c -F/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks -framework AE
ld: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/AE.framework/AE 'AE.framework' is a subframework. Link against the umbrella framework 'ApplicationServices.framework' instead.


This is because Apple wants to retain the freedom to re-factor these frameworks, and if you link through the umbrella, we can move symbols around without breaking your app.

However, ApplicationServices, does bring in other top level frameworks, e.g. CoreServices, that you can link to independently. So if you just need stuff from CoreServices, then it probably is better to just link to CoreServices.

If the framework is in /System/Library/Frameworks, it will be one you can link against. But pretty much all the frameworks further down are sub-frameworks, and you can't link against them.

On Feb 1, 2005, at 8:08 AM, James Bucanek wrote:

Greetings,
I need a little wisdom from those that have been working with XCode for awhile.
I just added a Carbon call to my Cocoa/Obj-C project (LSCopyItemInfoForRef) and the build died when it got to the linker. So I played around, and finally decided to add the "ApplicationServices.framework" to my External Frameworks and Libraries. The program now links and runs just fine.
Poking around a bit, I discovered that the ApplicationServices.framework is actually a collection of other frameworks (about a dozen), most of which I'll never use.
Is there anything "bad" about linking against some large collection of frameworks that you don't reference? Am I bloating the link tables of my application, or creating run-time dependencies that I shouldn't?
On the other hand, it there anything "bad" about digging into a collection of frameworks like ApplicationServices and trying to link to just the one or two specific sub-frameworks directly? Should one stay out of the details of frameworks, just and one should stay out of details of packages?
--
James Bucanek <mailto:email@hidden>
_______________________________________________
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

_______________________________________________ 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
References: 
 >Stupid Linker Question (From: James Bucanek <email@hidden>)

  • Prev by Date: Re: Stupid Linker Question
  • Next by Date: Re: Problem Debugging GNU Make Projects
  • Previous by thread: Re: Stupid Linker Question
  • Next by thread: Re: Problem Debugging GNU Make Projects
  • Index(es):
    • Date
    • Thread