site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com