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: Peter O'Gorman <email@hidden>
- Date: Mon, 25 Feb 2008 01:52:53 -0600
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). 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.
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.
>
> 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).
Peter
--
Peter O'Gorman
http://pogma.com
_______________________________________________
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