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: Sat, 31 Dec 2005 20:55:02 -0800
On Dec 31, 2005, at 5:34 PM, Bill Northcott wrote:
On 01/01/2006, at 2:12 AM, Steve Checkoway wrote:
Look at the way Apple do it with open source stuff. They use a
'dst' directory buried in /private/tmp or you home directory.
that way the final install_name path will always be shorter. I
have done this a lot and never had to lengthen a name.
You're right, that does sound like the way to go for that sort of
thing. I'm not completely positive at this point, but I think my
point was that the fact that one has to do this sort of thing at
all is bad.
Of course we can just differ on whether this is good or bad thing.
My perspective is that, used properly. it guarantees that the right
dylib will be used at runtime regardless of how many other versions
may be installed. The alternative of changing the runtime search
paths can break other packages. Install_names can't do that.
I think it is worth the learning curve and slight added
complication for this benefit.
Ensuring that the version of the library you intended can be a good
thing without a doubt; however, what happens when a newer version of
a library is released and the install name of a particular library
includes the full version?
$ otool -D /usr/lib/libssl.dylib
/usr/lib/libssl.dylib:
/usr/lib/libssl.0.9.7.dylib
What happens when libcssl.0.9.8 is installed by Apple on my computer?
I will have to recompile everything against the new version. Perhaps
this isn't a fundamental flaw of install names but if Apple has the
wrong install names (or is it intended that everyone's software break
if it links with libssl and new version is included in a future
software update?) how are we to deal with that?
If the user is changing the runtime library search paths then
presumably they know what they are doing and can live with the
consequences if it doesn't work out quite as well as planned. Just
having my software be completely dependent on a bug fix version of a
library that is _very_ likely to change (http://www.openssl.org/
source/ 0.9.8a looks like the latest to me) seems like a poor choice
to 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