Re: Question about dynamic and static libraries
Re: Question about dynamic and static libraries
- Subject: Re: Question about dynamic and static libraries
- From: Bill Northcott <email@hidden>
- Date: Sat, 31 Dec 2005 09:44:43 +1100
On 29/12/2005, at 6:12 PM, Ladd Van Tol wrote:
They are not needed. So Apple tools like Xcode don't support
them. You can use them as long as you stay inside the ./configure/
make/make install build method.
This is not at all true. There are plenty of cases where one would
desire a static library. For example:
1. If you're pulling in an auto-conf'ed lib, but wish to dead code
and symbol strip it for your built product. If you're operating
under a size constraint, this can become important
I would agree with that. I find the easiest way to do this is to use
GNU libtool. If you designate the library as a convenience library,
then libtool will put the whole path in the link instead of '-lfoo'
and it does not matter how many other copies you have hanging around.
2. If you're building a command line tool that needs an auto-
conf'ed library, and you don't want to spray dylibs all over the
system
Really there is never any need to spray dylibs around. It is doing
this that causes the problems. If you don't want the dylib why build
it in the first place? That is a waste of time as well as a source
of trouble.
3. If you don't want to spend a lot of time fooling around with
frameworks and install paths
My whole point is that once you understand the structure of a
framework, it does not take a lot of time. You only need a few lines
of shell script in configure.in to build a framework.
4. If you have a case where the performance of calling functions in
your library is important
I have not tested it, but as Apple tell it, there is no significant
performance difference between a static and dynamic link on MacOS X.
I know this is not true on other platforms.
Remember: your use case is not the same as everyone else's.
but I have done work setting up MacOS X builds for a number of open
source packages.
Cheers
Bill
_______________________________________________
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