site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) David Elliott wrote:

Hi Peter,

Hi David,

...

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. 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.

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.

No, I have to disagree. If someone uses the new symbols in the new libiconv then their application will not work with the older libiconv, that is what the whole compatibility_version is about. Older applications which use only the functions in the older library will continue to work with the new library, but newer applications using functions only present in the new library will not work with the old. This is how it should be. When interfaces are removed then the install_name (soname) of the library should change and the compatibility_version etc start at the beginning again. If you have complaints or suggestions for the libtool versioning scheme on darwin, please bring them up on libtool@gnu.org, and I will answer them there. I do not think that the versioning scheme can now change, however, as it would introduce binary compatibility issues.

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.

I do not think that crashing like that is the desired behavior, if that were desired then compatibility_version would be unnecessary.

...

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.

That is inaccurate versioning, in my opinion. Applications linked to the new library may not be compatible with the old. 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