Re: including dylibs in my .app
Re: including dylibs in my .app
- Subject: Re: including dylibs in my .app
- From: Dan Korn <email@hidden>
- Date: Fri, 29 May 2009 15:25:00 -0500
On May 29, 2009, at 2:10 PM, Tommy Nordgren wrote:
The problem is not with disk space. When a library is put inside
the Application bundle,
every app that uses the same library will need it's own in-memory
copy of the code,
because each app will use it's own copy of the library on disk.
Even if the code is the same, it can't be shared when each library
instance have it's own on-disk
path.
Yes, and if the library in question is a third-party library, and
these multiple applications are all potentially using different
versions of it, then encapsulating and isolating each instance of the
library within each application and avoiding "DLL Hell" is a Very Good
Thing. That's the beauty of Apple's framework/bundle concept.
Unfortunately, Apple's development tools are not quite as slick.
Developers of third-party libraries and frameworks can't anticipate
how their libraries are going to be used by other developers.
Therefore Xcode, being Apple's high-level development tool for
creating application bundles, should make it easier to use such
libraries, even with its Unix-based linker, without having to resort
to modifying third-party libraries with low-level command-line
utilities like install_name_tool. Or at least allow this to be
managed in the GUI. I mean, if I tell Xcode to put a library inside
my application's bundle, then I probably want to actually link to it
there and load it from there at runtime.
In sort, it should be up to the application using the library to
dictate the location from whence it should be loaded, not the other
way around.
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