Re: Question about dynamic and static libraries
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