• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
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


  • 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

  • Follow-Ups:
    • Re: Question about dynamic and static libraries
      • From: Bill Northcott <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>)
 >Re: Question about dynamic and static libraries (From: Bill Northcott <email@hidden>)

  • Prev by Date: Re: Question about dynamic and static libraries
  • Next by Date: setting custom compiler
  • Previous by thread: Re: Question about dynamic and static libraries
  • Next by thread: Re: Question about dynamic and static libraries
  • Index(es):
    • Date
    • Thread