site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Peter, On Feb 25, 2008, at 10:57 AM, Peter O'Gorman wrote: [big snip] 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. You're absolutely right. I refreshed my memory: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Conc... -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... David Elliott wrote: 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. No, I understood, but now that Apple have shipped Leopard with libiconv with a compatibility version of 7.0.0, they can not reduce it because any currently shipping binaries that were linked on Leopard will stop working on leopard. Not a good plan. Actually they could reduce it to compat 5.0.0, current 7.0.0 and no existing apps would break. However, I do see your other point. See below. If you require that your application run on Tiger and Leopard, you can always use the 10.4 SDK. But, if Apple had spent the time and effort to inspect all their open source projects and modify the headers and libraries then you would be able to use 10.5 features on 10.5 and put -mmacosx_version_min=10.4 in the compiler and linker flags to ensure that the new interfaces were marked weak. Apple has not done that for 10.5, with an enhancement request they may do it for 10.6. The problem is that using an older SDK is not an option when you must be able to link to newer versions of other libraries. That is inaccurate versioning, in my opinion. Applications linked to the new library may not be compatible with the old. What happens is that you see libSystem and most of the other Apple- developed libraries completely breaking this convention because they have deferred compatibility checking to a higher level. Indeed it is true that when you add an interface you must increment the compatibility version because some random person using the library in the normal way will expect those functions to exist. And therein lies the failing of dyld's versioning scheme. If I never use any of the added symbols, and I know I do not use them then there ought to be a way I can specify through some ld options that I can use an older version. Or better still perhaps I can specify an option that I'd like ld to scan for the symbols I actually use and set the compatibility version to the lowest possible containing all of those symbols. For that to happen the dylib would of course need to actually have some amount of per-symbol versioning which dylibs do not at this time have. That's okay though as it makes me feel a lot better about my scheme to simply grab /usr/lib/libiconv.dylib and bump its compatibility version down to 5.0.0. Its current version can stay as is to document that it really was linked against 7.0.0. I then need only place the hacked libiconv.dylib in one of the -L paths and all is well. To handle the added symbols I simply need to make sure to use the weak-linking features, if I even need those symbols at all. Thanks for taking the time to get my mind right on this again. I'll have to add per-symbol versioning to my growing list of dreams. Theoretically, it would be possible to implement by only changing the static link editor to record more information when making a library and to use that information when linking to it. Dyld need not even consider it. This email sent to site_archiver@lists.apple.com