site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Peter, On Feb 25, 2008, at 2:52 AM, Peter O'Gorman wrote: David Elliott wrote: 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). 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. Thanks a bunch! -Dave _______________________________________________ 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... 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. 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. 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. This email sent to site_archiver@lists.apple.com