Re: Using weak linking and other techniques with non-Apple libs
Re: Using weak linking and other techniques with non-Apple libs
- Subject: Re: Using weak linking and other techniques with non-Apple libs
- From: David Elliott <email@hidden>
- Date: Mon, 25 Feb 2008 03:24:00 -0500
Hi Peter,
On Feb 25, 2008, at 2:52 AM, Peter O'Gorman wrote:
David Elliott wrote:
In lieu of Apple changing the library to use compatibility version
5.0.0
current version 7.0.0 (which would probably be the better thing to
do)
is there some way I can do this myself? One hack I have tried is to
simply grab the /usr/lib/libiconv from the 10.4 SDK and drop it in
one
of the directories on the linker's -L path. This seems to work
without
problem now but I'm thinking that if we were to ever use new symbols
present only in the newer library versions, even if weak-linking to
them
similar to the above, we'd be in trouble.
Apple will never go back and lower the compatibility version, it would
cause applications using libiconv built on Leopard to cease working
(requiring version 7.0 but libiconv is 5.0).
I think you misunderstood me. This is exactly the case now. You
cannot build against libiconv from Leopard and run on anything other
than Leopard because dyld will kill your program immediately at
startup because your program says it requires 7.0.0 and Tiger only has
5.0.0.
Even if you never use the new libiconv functions, you still can't run
if you linked to libiconv. On a Linux system, this would not be the
case. The soname would be the same (e.g. libiconv.so.X) but the
versioning info would be incremented appropriately. On Darwin the
appropriate thing to do is leave the full name the same (e.g. /usr/lib/
libiconv.X.dylib) and increment the current version but not the
compatibility version.
What would happen in both cases on Linux and Darwin is that the app
will crash when trying to bind missing symbols if and only if it
actually uses the newer symbols.
That being said, I think
that you ought to file an enhancement request on this. Currently,
Apple
builds open source projects as designed, and uses the library versions
supplied by upstream. In the case where there is only added API
however
(such as the libiconv version bump) it would be better if Apple were
to
patch the headers to include AvailabilityMacros.h and mark the added
api
as available in mac os x version whatever and later.
I am actually happy to do it myself when needed but the library
versioning then prevents me from actually using the libraries on the
old system.
There are, however, a large number of open source projects that are
responsible for many of the libraries in /usr/lib, it may be too
burdensome to expect Apple to inspect and patch all of them like this.
Still, does not hurt to ask.
Right. Like I said, just having accurate library versioning (e.g.
compatibility 5.0.0 current 7.0.0) would be enough. I can figure out
myself which functions are present in which OS X releases.
I forget which document it is that I read on Apple's site but a couple
of years ago read that document and designed the scheme to get it
right for Bakefile and thus wx. That is, make it so that libtool-
style versioning translates both to ELF versioning as well as dyld
versioning.
It's also worth pointing out that per-symbol versioning info is
becoming more common in upstream sources. For example, wxWidgets has
an out of source scheme suitable for Linux builds but I don't see any
reason we couldn't add an in-source scheme, particularly if this was
desirable for Apple.
On the other hand, it looks like Apple does something really odd with
the wx library versions that they ship. I am almost positive we
didn't ship 2.8.4 with current version 2.8.4 compatibility version
2.6.0. The major version (e.g. 2.8) is actually coded as part of the
library name, the soname is that plus the first component of the
libtool version (which is also incidentally part of the dylib's full
name) and the remaining libtool version components (which have nothing
to do with the library version) are used for the dyld versioning info
with the compatibility version being the earliest release.
Why they decided to do that after we got it all correct (at least as
far as I'm aware) boggles my mind.
It's also sort of a pain to have to find an copy the old version.
So I
was wondering if there is some equivalent to install_name_tool that I
can use to change the versioning info. For instance, grab
libiconv.dylib from either the SDK being used to build (or the
system),
modify the compatibility version number, and place the modified copy
into a directory on the linker's -L path.
As far as I know, it would be rather trivial to write such a tool
and if
there isn't one I'll do it. But I figured I'd ask before embarking
on
that.
I did a quick hack version one evening several months ago
http://pogma.com/misc/editlib.c (it edits the library in place, so
make
a copy first - better yet, make something that is not a quick hack).
I suggest that you copy your libiconv, edit the headers and then edit
the compatibility versions etc, then put your new headers and
library at
the head of your -I and -L paths (thus avoiding the need to edit the
system library and header - usually not a good plan).
No need to edit the headers. It's enough to just reprototype with the
right availability macro after including the usual headers. And yes,
I already figured out that I need to edit the version of the library.
Thanks for the source. I was hoping someone had done something similar
enough I could borrow it to get started.
Thanks a bunch!
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden