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: Dan Korn <email@hidden>
- Date: Tue, 18 Mar 2008 15:20:19 -0500
On Mar 18, 2008, at 1:44 PM, Jean-Daniel Dupas wrote:
You can use install_name_tool to modify the "Intall path" of th
third party library:
install_name_tool -id @loader_path/../what/you/want/
third_party.dylib third_party.dylib
Then all files linked using this library will have the path you
choose.
Else, you will have to use lipo to flatten your binary, use
install_name_tool on each arch, and then lipo to recreate an UB, but
I don't think I will choose this way.
Thanks Jean-Daniel. Calling install_name_tool with the -id option, on
the framework, does seem to work, even if the framework doesn't
support the current architecture.
But regardless of whether install_name_tool works reliably with the -
id option, the fact that install_name_tool with the -change option
fails, depending on the architecture on which it is invoked, not on
the architectures of either the executable whose loading table is
being modified or the libraries which are being loaded, is a bug, IMHO.
And in the end, I still want to be able to link to a third-party
framework or dylib without modifying it.
It should be up to the executable doing the linking to decide where to
find its dependencies; the libraries being loaded should not dictate
the loading path to the executable. I understand that things work a
certain way by default with the command-line tools that Xcode is
wrapping (even though most of those were developed or modified by
Apple, to fit into the Universal Binary and Framework paradigms which
they created), and I also understand that the OS X architecture itself
precludes the ability for an executable to be able to search multiple
locations for its dependent libraries (unlike on other operating
systems, including that other one that starts with a "W"). However, I
maintain that when you're using an IDE such as Xcode, it should be
smart enough to figure out that you want to load the library from
where you're including it in your own bundle. Having to go to the
command-line at all to do something as basic as this is a deficiency
in the IDE.
So there seem to be two issues here for Apple to address: One there
should be a reliable way to link to a third-party library, at a
location of the executable's choice, without modifying the third-party
binary, and regardless of the architecture on which anything is built;
and Two, when you include a framework or dylib in your own bundle in
Xcode, the IDE should automatically do whatever needs to be done so
that the framework or dylib can be loaded from that location. I'd
love to hear some feedback from one of the Apple engineers about this.
Aren't other people out there running into these same kinds of issues
with third-party libraries? And if so, do you consider modifying the
third-party binaries to be an acceptable solution?
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