Re: static libraries
Re: static libraries
- Subject: Re: static libraries
- From: Steve Checkoway <email@hidden>
- Date: Sun, 23 Oct 2005 17:23:30 -0700
On Oct 23, 2005, at 4:35 PM, Bill Northcott wrote:
On 24/10/2005, at 3:59 AM, Steve Checkoway wrote:
So, if ld searches in any path where ld can locate a dylib, it will
select this first - no matter what you have dragged in into your
project. Xcode just takes the canonical name and passes it to ld
(through gcc).
In order to avoid conflicts, we probably need to specify full paths
and full names. *sigh*
Yeah. =( I assume this has been filed as a bug before.
I very much doubt that Apple will regard this as a bug. Their
position on the use of static libraries is clear - somewhere
between deprecated and totally unsupported.
This is stupid, a static library is nothing more than an archive of
object files with a table of contents. If XCode supports object
files, then there is zero reason to not support static libraries.
There are a couple of good reasons for this:
1. all the usual stuff about being able to update dynamic
libraries without needing to rebuild linked executables.
and
I have found performance, in this regard, to be lacking. If you pass
a symlink to a dynamic library, it resolves the symlink to, say,
libcrypto.dylib, it will resolve to libcrypto.0.9.7.dylib. If you
replace that with something newer, say, libcrypto.0.9.8.dylib, your
old application will not run.
Even worse, if you give the application to someone else who has a
different version of the library, it won't launch.
Still worse, dynamic libraries have the installed path hardcoded into
both the library and the application so one cannot say, "This
requires libfoo to run," because you might have installed it with
fink and the library is in /sw/lib and they might decided to use
darwinports and have it in /opt/local/lib. The only way you can
actually _use_ dynamic libraries is if they are already installed in /
usr/lib. So where does that leave you? Either statically link the
libraries or use Frameworks.
If XCode fails at static libraries, we're stuck with Frameworks. Now,
I like the idea of frameworks that can be installed in different
places including in the application bundle, but that means that you
have to build the library as a framework and distribute it along with
the application. This defeats the whole purpose of dynamic libraries
in the first place (well, the multiple processes using the same
dynamic library part anyway). In fact, with a static library, the
parts of the code that aren't used can be stripped from the final
binary. If you're distributing a framework in the app bundle, you
have to include the whole thing which potentially increases the size.
2. the fact that Xcode has more than one compiler which are
incompatible at the object code level. If you build a static
library with gcc-3.3 and attempt to link it with object code built
with gcc-4 it will fail. The only static libraries which Apple
ships are buried in the gcc trees. So this cannot happen.
Are you sure about that?
$ cat foo.c
#include <stdio.h>
void foo() { printf("Compiled with gcc %d\n", __GNUC__); }
$ gcc-3.3 foo.c -c -Wall
$ cat bar.c
extern void foo();
int main() { foo(); return 0; }
$ gcc-4.0 bar.c -c -Wall
$ gcc foo.o bar.o
$ ./a.out
Compiled with gcc 3
Looks like it linked correctly to me.
Here's one good reason to use static libraries: Your boss says,
"These libraries must be dynamically linked, while those must be
statically linked." What are you supposed to say? "Sorry boss, Apple
says they don't like static libs so I have to do it their way"?
As a side note, the best way I've found to get dynamic libraries
working correctly--and by correctly, I mean better than the way they
currently do--is to dlopen() them. This actually searches for the
libraries in multiple directories rather than just looking for one
specific path. However, this is a hassle. If I am looking for libfoo,
I don't care where it is located and if I want to test a new version
of a library, I'd like to be able to do that without rebuilding or
replacing the library.
- Steve
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