Re: ANN: Audio IB Palette
Re: ANN: Audio IB Palette
- Subject: Re: ANN: Audio IB Palette
- From: Doug Wyatt <email@hidden>
- Date: Thu, 10 Oct 2002 02:33:08 -0700
On Wednesday, Oct 9, 2002, at 22:18 US/Pacific, Andrew Kimpton wrote:
That's the way our linker works -- unless you load symbols
individually from a library (which is a whole 'nother ball of wax),
libraries contain paths to the dynamic libraries they're linked
against. Notice the funky syntax for embedded frameworks:
@executable_path/../Frameworks
This works fine for applications but doesn't seem to work for other
types of bundles. For example when I built a framework this way and
included it inside my AU Component bundle in
Contents/Frameworks/blah.framework my component failed to load due to
an inability to load the
@executable_path/../Frameworks/blah.framework/... files. I can only
surmise that the runtime linker was attempting to resolve
@executable_path with the bundle of my host application (which since
it was a trivial command line app wasn't going to work). Is there an
equivalent mechanism for plugins, components or other similarly
dynamically loaded code to resolve the frameworks that they might need
or do I either a) need to install my private framework somewhere
'global' or b) build my component with a static library ?
It boils down to a tradeoff between
- not installing duplicated code, exposing your private framework to
the world, giving the user another file to look at and wonder what it
does
- the extra size of linking your library statically into multiple
pieces and not being able to share it
Your framework is not going to be findable by any other pieces if it's
buried in a component bundle anyways.
If it's important to you that you (and potentially others) be able to
link lots of components (note lowercase 'c') to this library, then it's
worth making it a framework. Otherwise I'd make it a static library.
In our PublicUtility directory in the SDK is a class called
CASharedLibrary; you might take a look at that for an example of how to
dynamically look up symbols at runtime if you want to go that route
(it's messy, we don't do it except in rare cases, to avoid undesirable
or circular dependencies between libraries).
hth,
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.