Re: Xcode, Dyld, External Dynamic Libraries and Setting {DY}LD_LIBRARY_PATH for Running Targets
Re: Xcode, Dyld, External Dynamic Libraries and Setting {DY}LD_LIBRARY_PATH for Running Targets
- Subject: Re: Xcode, Dyld, External Dynamic Libraries and Setting {DY}LD_LIBRARY_PATH for Running Targets
- From: Ken Thomases <email@hidden>
- Date: Sat, 25 Jul 2009 04:35:48 -0500
On Jul 25, 2009, at 1:17 AM, Grant Erickson wrote:
On 7/24/09 10:20 PM, Ken Thomases wrote:
Typically, you would not install libraries into any place like /
Library/Application Support/Nuovations/lib. Stuff in Application
Support should not be critical to the functioning of your app.
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Artic
les/LibraryDirectory.html>
Rather, the libraries necessary for your app to run should be inside
the app bundle. Usually, in MyApp.app/Contents/Frameworks.
<http://developer.apple.com/documentation/CoreFOundation/Conceptual/CFBundles/
BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19
I've done in-bundle frameworks previously for standalone
applications or
plug-ins; however, given that the five frameworks and two shared
libraries
in question here are leveraged across a preference pane and three
applications, duplicating all those resources in each bundle seemed
inappropriate.
Well, according the first link, above, they should go in /Library/
Frameworks or ~/Library/Frameworks. If they are very closely related,
I would try to package them into a single overarching framework if I
could.
Both Apple's iWork '09 and Adobe appear to have both shared
frameworks and
dynamic libraries in Application Support. Those seemed like reasonable
parallels to this circumstance as those are instances of multiple
applications sharing common executable code resources among them.
Yeah, I don't know the thinking that went behind those products'
decisions. I can only point to the guidelines, which I think are
generally sound. There are always exceptions, although I would hope
they would be necessary rather than on-a-whim exceptions. Since
neither of us seems to understand why those apps are deviating from
the guidelines, it doesn't seem wise to me to blindly follow their
example. Their reasons may not apply to your case.
On the other hand, I take your point of "well, how much trouble could
it cause me, if they're doing it?" :)
Is such framework and/or dynamic library sharing typically
discouraged?
No, not in cases which warrant such sharing. (I would say it's
discouraged if there's no good reason for it. Put another way, I
think that self-contained apps and plug-ins are preferred, up to the
point where that starts to conflict with other design goals.) The
only reason I suggested preferring a self-contained app bundle is
because you didn't originally make any mention of the libraries being
shared across multiple apps/pref panes. It seems you have sound
reasons to put those shared libraries and frameworks in a common
location.
In any case, the Run Script build phase and install_name_tool would be
how you change the library references within your executables to point
to the ultimate destination, which is what it seemed you were mostly
looking for. Obviously, you won't be able to use @executable_path in
your case.
Regards,
Ken
_______________________________________________
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