Re: Question about dynamic and static libraries
Re: Question about dynamic and static libraries
- Subject: Re: Question about dynamic and static libraries
- From: Bill Northcott <email@hidden>
- Date: Thu, 29 Dec 2005 13:30:19 +1100
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.
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.
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 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.
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.
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.
Cheers
Bill
_______________________________________________
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