Re: including dylibs in my .app
Re: including dylibs in my .app
- Subject: Re: including dylibs in my .app
- From: Jason Foreman <email@hidden>
- Date: Fri, 29 May 2009 14:35:23 -0500
On Fri, May 29, 2009 at 2:10 PM, Tommy Nordgren
<email@hidden> wrote:
>
> On May 29, 2009, at 7:16 PM, Taylor Holliday wrote:
>
>> Is it really that bad to potentially duplicate a few libs? I'd rather
>> have a self-contained .app that doesn't require an installer.
>>
> 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. (There is no way for the dynamic loader to know that two library
> instances are the same,
> even if they have the same file name except for the directory part.
>>
While what you say is true, there can be some issues when dealing with
non-system shared libraries. For example, there may be more than one
application that wants to use a particular shared library. It is
possible that another application might install libs to a shared
location (/usr/local, whatever) that are incompatible with the
versions your application requires. The safest action is to include
any non-system libs in your application bundle.
That said, I don't believe there is a single correct answer. In some
cases, embedding the libs in the app bundle might make more sense,
while in other cases it might be appropriate to install to a shared
location. Either way is valid, and it is up to the application
developer to make that decision.
Jason
_______________________________________________
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