• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: static libraries
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

References: 
 >Re: static libraries (From: Bill Northcott <email@hidden>)

  • Prev by Date: Re: xcode and CVS
  • Next by Date: jam fails with exit status 1.
  • Previous by thread: Re: static libraries
  • Next by thread: Proper address for Xcode feedback
  • Index(es):
    • Date
    • Thread