Re: Question about dynamic and static libraries
Re: Question about dynamic and static libraries
- Subject: Re: Question about dynamic and static libraries
- From: Steve Checkoway <email@hidden>
- Date: Mon, 2 Jan 2006 16:06:56 -0800
On Jan 2, 2006, at 3:42 PM, Thomas Engelmeier wrote:
You get the same behavior for calls into that lib *all the time*,
even across OS platforms, and not some hard reproducible support
call because user installed rev x.y of that .dylib by the means
of dports et al.
If you include _your_ private snapshot of that library as .dylib
in you app, chances are you loose diskspace - with a dylib there
is no chance the linker can strip e.g. most of the libtiff code
because it is only used to embed an color profile tag into DNG
files.
The linker has a chance, even with dynamic libraries.
So instead of filing a Radar about poor static library handling,
filing one for stripping dylibs for specific application use? Just
the way the linker would do it with static libraries?
That would be completely against the "nature" of a dylib. A
dynamic / shared library is intended to be used by an arbitrary
number of unrelated binaries, so striping symbols does not make any
sense.
As has been pointed out twice by Apple engineers in this thread,
static libraries are not deprecated.
I think that people have pointed out enough pros for both static and
dynamic libraries to see that both are good ideas.
As for stripping symbols from dynamic libraries, you have to be
careful in your terminology. Strip(1) can be used with the -x option
to remove all local symbols, leaving only the global ones. This is
done quite often with dynamic libraries.
I can think of a situation where stripping unused global symbols/code
from a dynamic library could be a good idea. If you have to link with
a dynamic library for some reason (probably a legal reason involving
certain software licenses [1]) and you have to distribute the library
with your application, it would be nice to trim the unused code.
- Steve
1. IANAL and do NOT want to discuss any such licenses with anyone, at
any time, for any reason.Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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