Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Question about dynamic and static libraries
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about dynamic and static libraries

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







References: 


 >Re: Question about dynamic and static libraries (From: Bill Northcott <email@hidden>)


 >Re: Question about dynamic and static libraries (From: Steve Checkoway <email@hidden>)























Visit the Apple Store online or at retail locations.

1-800-MY-APPLE


Contact Apple | Terms of Use | Privacy Policy


Copyright © 2011 Apple Inc. All rights reserved.