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 16:56:59 +1100
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?
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.
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.
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.
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