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 19:54:27 -0800
On Dec 28, 2005, at 6:30 PM, Bill Northcott wrote:
On 29/12/2005, at 11:00 AM, Steve Checkoway wrote:
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 would regard that as a UI issue for Xcode, and I agree it would
be nice if it warned you that it might not use the library you
dragged in. I thought you were discussing the build issue rather
than the UI. My mistake.
Perhaps it is a UI issue but there is no way to specify a static
library except by changing LDFLAGS to include the path.
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?
You get a bundle of errors at link time as many people have found.
Getting a bunch of errors seems worse than one concise error about
version mismatches.
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.
See 'man install_name_tool' and the documentation on frameworks
and other bundles What are your other issues?
I know all about install_name_tool, @executable_path, and Frameworks.
(Well, maybe not "all about.") The other issues pertain to how the
runtime locates libraries and the mach-o issues which require hacks
such as @executable_path and install_name_tool which I did touch on
below but isn't relevant to this discussion.
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.
Nasty! Once you pollute your system with Fink or Darwinports, you
really can't expect Xcode to do the management for you any
longer. There are just too many possibilities.
I'm not sure that I'd call it pollution. I just like to do things
with my computers other than have it sit there and look pretty
(which, frankly, it does) and sometimes this requires installing
software from the unix world. The point is, I don't want Xcode to do
the management for me. If I say X, chances are that I mean X.
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.
No really, use install_name_tool. Mucking with search paths is a
'no no' except for testing. Been there and done that. It was a
mistake. I have several people on open source projects argue with
me that dylibs are not practical until they see it done properly.
I really regard install_name_tool as a hack. I'm not sure I agree
that changing search paths is a mistake. One just needs to know how
it works on a particular system. I understand how apple's ld searches
paths (it is in the man page after all). The issue is that Xcode
doesn't do what I tell it to do.
IMHO the root problem is thinking that MacOS X is, or should be,
Linux. It is not. On Linux you put non-system libraries in /usr/
local. On MacOS X you should package them as a framework and put
them in /Library/Frameworks or ~/Library/Frameworks as
appropriate. Then everything works much more smoothly. Many
opensource projects already do this and more are changing over as
they realise the advantages.
I agree that it isn't like linux and that libraries should be
packaged as frameworks. Believe me, I _really_ like the concept of
frameworks and I wish that was the direction that *nix had gone when
it was first developing dynamic libraries. The reality is that it
didn't and most libraries do not come as frameworks. Since I don't
want to be responsible for maintaining the frameworks for all of the
libraries that I use, I'm forced to build the framework once and
package it in My Great App.app/Contents/Frameworks.
From working with cross-platform application, I know how hard it is
to deal with multiple build systems and multiple file layouts for the
installed files. It's so painful that the tendency is to make it look
the same on every platform.
Were I to write a *nix library, I'd probably be tempted to just use
the GNU autotools and leave it at that unless someone else went to
the trouble of writing some autoconf or automake macro (frankly, I
still have no idea why some are AC_ and other are AM_) to build the
framework for me.
- 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