Re: ANN: Audio IB Palette
Re: ANN: Audio IB Palette
- Subject: Re: ANN: Audio IB Palette
- From: Andrew Kimpton <email@hidden>
- Date: Wed, 09 Oct 2002 22:18:14 -0700
Doug Wyatt wrote:
On Saturday, Oct 5, 2002, at 06:10 US/Pacific, Robert Grant wrote:
This morning I've been investigating embedded frameworks (within an
application)
and that seems the best way to go. Except that it would have to be
embedded in both
the palette and the app which seems weird. Another weird thing is when
I tested the
app with an embedded framework on another machine it still tries to use
the absolute
build path. Perhaps I should be doing something with the install
options?
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 ?
Doug
Andrew 8-)
_______________________________________________
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.