Linking to third-party Frameworks and dylibs from a plug-in
Linking to third-party Frameworks and dylibs from a plug-in
- Subject: Linking to third-party Frameworks and dylibs from a plug-in
- From: Dan Korn <email@hidden>
- Date: Mon, 10 Mar 2008 13:58:15 -0500
I'm using Xcode 2.5 to build a plug-in to a third-party application.
Both the plug-in and the application are Mach-O Universal Binary (ppc
and i386, 32-bit). My plug-in uses several third-party libraries
which I have received as Frameworks and dylibs.
I've tried to put the Frameworks and dylibs in both /Library/
Frameworks and in the Frameworks folder in my plug-in's bundle, with
no success. I get messages like this in the Console log, for several
of them:
Library not loaded: @executable_path/../Frameworks/<library
name>.dylib
If I use otool -L on any of these dylibs or Frameworks, it seems to
indicate that each Framework or dylib has been built with its
INSTALL_PATH set to one of these two values:
@executable_path/../Frameworks/
$(USER_LIBRARY_DIR)/Frameworks
I have the source code and Xcode projects for a couple of these third-
party components, so I could change the INSTALL_PATH and rebuild them,
but neither of the above paths seems to work for embedding a Framework
inside my plug-in bundle, and I don't have access to the source to
rebuild every third-party dylib or Framework I want to link to
anyway. I know that I can use install_name_tool from a shell script
to modify the INSTALL_PATH of an already-built Framework, but that
seems like a messy hack. I'd really prefer not to have to rebuild or
modify the third-party components in any way.
I read the "Locations for Private Frameworks" section of the Framework
Programming Guide, but it only talks about using a Private Framework
in your own monolithic application. Plug-ins don't seem to have been
accounted for completely in this Frameworks paradigm. It seems to me
that it would make more sense for my executable to be able to specify
the location of the Frameworks it wants to load, rather than having
the Frameworks dictate their own fixed installation locations. Unless
I'm missing something, it doesn't seem possible to build a single
Framework which can be used either privately or shared.
I used otool -L to peek into some of the other plug-ins which use
embedded Frameworks of their own, and they seem to work around this
issue by modifying the INSTALL_PATH to take the Plug-ins folder of the
application into account, like so:
@executable_path/../Plug-ins/<plug-in name>/Frameworks/<framework
name>/Versions/A/<executable name>
However, this is problematic as well, because it relies on the names
of both my plug-in and the folder in which the plug-in is loaded by
the application to never change. It also makes the Framework unusable
in any other context. This all seems way too locked-down for the Mac
world where the user is supposed to be able to move applications
around and still have them work.
I could install the frameworks in the application's own Frameworks
folder, but that seems a bit rude, and defeats the purpose of being
able to keep all the parts of the plug-in executable in its own bundle.
So, my question is, is there another way to make this work? Ideally,
I'd like to just be able to take any third-party Framework and link my
plug-in to it, and have it work even if the names or installed
locations of things change, and even if I move it out of my plug-in's
bundle to a shared location.
Thanks,
Dan
_______________________________________________
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