• 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 22:38:35 -0800


On Dec 28, 2005, at 9:56 PM, Bill Northcott wrote:

On 29/12/2005, at 2:54 PM, Steve Checkoway wrote:

(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.

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.

Now I am confused. Do you want to do it or do you think the Xcode GUI should do it for you?

Depends on your point of view I suppose. If I drag a static library into the Xcode GUI, it should use the static library because I explicitly chose it. I would consider that me doing one thing and Xcode deciding to do something else. I suppose one could argue that that is me wanting Xcode to do something for me.



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.

Frameworks are not hard. If you are packaging a GNU library, all that is needed is to set up the directory hierarchy, put the headers in Headers and the dylib with the same name as the framework and the appropriate install_name. You can use a symlink with the framework name if you want.. Install names can be relative as well as absolute so that hierarchies of frameworks can be 'drag n' drop' installed.


install_name_tool is so not a hack. It is an essential component of the framework system. OTOH changing search paths IS a hack and should only be used for testing.

My claim that install_name_tool is a hack is because it is used to change library names after they've been built. To ensure that it can even be used, one must pass -header-pad_max_install_names to ld. That is unlikely to have been passed in the first place. Since install names are specified as arguments to ld, the nonhackish way to do it is to just specify the correct name initially. Install_name_tool is only required to move the library which where the hack comes in. I maintain that relying on it as an essential build component is wrong.


Let's assume that I want to make a framework out of libfoo. I download, compile, and install it. Then I set up all of the required directory structure, copy the headers and rename libfoo.dylib to foo and put it in the correct place. Now all I need to do is use install_name_tool right? Okay, I need to change the install name from the following line to the next

/usr/local/lib/libfoo.dylib
@executable_path/../Frameworks/foo.framework/Versions/A/foo

assuming that I want package the framework with my app. Well, I'm out of luck since the second name is so much longer than the first. One way or another, I have to hack around this problem.


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.

Of course but then you can't legitimately complain if the platform specific build tool like Xcode does not work with your cross- platform file layout.

It might be nice if things that work on most (all?) other *nixen worked on OS X. One of those is intelligent dynamic library paths.



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.

There is nothing to stop you using GNU autotools to build a framework. Look at packages like Tcl/Tk or R.

Those are good examples. I appreciate that it can be done, it is just more effort for an issue that (in my opinion) shouldn't exist in the first place.


- 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>)
 >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: Re: Question about dynamic and static libraries
  • Previous by thread: Re: Question about dynamic and static libraries
  • Next by thread: Re: Question about dynamic and static libraries
  • Index(es):
    • Date
    • Thread