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: Wed, 28 Dec 2005 16:00:40 -0800
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.
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?
If the library is useful in more than one project, make it
dynamic. If not, build it in the source tree of the project and
don't install it.
Things aren't always this cut and dry. For one thing, making a
dynamic library out of it isn't usually feasible since mach-o's use
of dynamic libraries leaves a lot to be desired. I'm referring to the
install name of a library being required to be compiled into the
application. If you want to distribute your application, not only do
you have to distribute the dynamic library with it but also install
it in the same location. There are other issues with dynamic
libraries that I won't get into here.
The place where this bit me was where my static libraries were in
CVS. Since I can't just require that people have libfoo installed
(because it's unlikely to be installed on the users' systems in the
same place it is on mine and I don't care to dlopen _every_ library)
and I didn't want to require all of the unmodified source code of
other open source projects be in our CVS repository, I built the
libraries myself and put them in CVS. I had many of these same
libraries installed by hand in /usr/local/lib or by darwinports in /
opt/local/lib and, unbeknownst to me at the time, Xcode decided that
it wasn't going to use the static versions that I had built but the
dynamic versions in those directories.
In my case--and I would imagine in the majority of cases--dynamic
libraries were not feasible and static libraries were broken in
Xcode. Yes, I consider the current behavior to be a bug. Yes, I know
how to get around it using the "search paths first" linker flag or
just renaming the libraries. And yes, this e-mail is too long.
- 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