Re: Question about dynamic and static libraries
Re: Question about dynamic and static libraries
- Subject: Re: Question about dynamic and static libraries
- From: Eric Albert <email@hidden>
- Date: Wed, 28 Dec 2005 16:08:48 -0800
On Dec 28, 2005, at 4:00 PM, Steve Checkoway wrote:
On Dec 28, 2005, at 2:36 PM, Bill Northcott wrote:
On 28/12/2005, at 8:59 PM, Eric Albert wrote:
Also, I'm noting a weird behavior. When I build my app, it will link
to the .dylib unless I delete the libraries from /usr/local/lib and
copy the .a file into my project. In that case, otool does not show
a
dependency on the .dylib. However, if I run the app on a machine
where
these files exist in /usr/local/lib, it will use the version of the
library from that directory. Why does this happen? How can I avoid
this? I want it to always use my static library.
The easiest thing to do is to not build the dynamic library version
at
all. You can often do that with configure scripts by running
'./configure --disabled-shared'. Oh, and delete the /usr/local/lib
bit
first. :)
This is not weird behaviour. There are very good reasons for he
behaviour.
I have to disagree with you. If I drag a static library into Xcode, I
want _that_ library to be used and I usually have a very good reason
for it. When Xcode passes libraries to the gcc I don't want symlinks
resolved for dynamic libraries and I want absolute or relative (my
choice!) paths passed for static libraries.
What I don't want is for Xcode to decide that maybe I really meant to
use -lfoo when I dragged /Users/me/some_project/libfoo.a into the
window, especially if libfoo.dylib exists in /usr/lib.
I'd suggest filing a bug report about that.
MacOS X ships with multiple compiler versions. You may well have gcc
2.95, gcc 3.x and gcc 4.x all installed. Dynamic libraries are
compiler independent. Static libraries, which are just object code
archives, are not compiler independent. You see plenty of problems
on these lists from people trying to link code from a static library
built with gcc 3 with some other objects built with gcc 4 and vice
versa. Linux distros tend to have a system compiler which was used
to build the system itself and all enhancements. so this issue is
less common.
For this and other good reasons, the use of static libraries is
deprecated on MacOS X. So the linker ld will always use a dynamic
library if it can find one on the search path.
If this is a problem then there must be a better solution such as
giving an error that the static library was produced with an
incompatible version of gcc, not just punting to dynamic libraries.
What other good reason is there to deprecate static libraries?
Frankly, deprecating static libraries sounds a whole lot like
deprecating object files since what is a static library but a group of
object files with an index?
I'm not aware of anything about static libraries being deprecated.
Many developers use them successfully; they work fine, and they'll
continue to work fine.
On the other hand, static executables have always been strongly
discouraged on Mac OS X and Apple doesn't ship static system libraries.
But both of those are very different from what you do with your own
libraries.
-Eric
_______________________________________________
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