Re: Linking to third-party Frameworks and dylibs from a plug-in
Re: Linking to third-party Frameworks and dylibs from a plug-in
- Subject: Re: Linking to third-party Frameworks and dylibs from a plug-in
- From: "William H. Schultz" <email@hidden>
- Date: Mon, 10 Mar 2008 14:16:26 -0700
If you need that much flexibility, you may need to load the libraries/
frameworks manually and call functions via extracted function
pointers. Otherwise, my solution has been to use install_name_tool to
modify the install path and placing these libraries/frameworks inside
the Application's Frameworks directory.
This inflexibility in the search paths is a common complaint, and it
is very un-Mac-like.
-------------------------------
Hank Schultz
Cedrus Corporation
http://www.cedrus.com/
On Mar 10, 2008, at 11:58 AM, Dan Korn wrote:
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
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
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