gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ABI Compatibility (was Re: Installation woes for the average user...


From: Wolfgang Lux
Subject: Re: ABI Compatibility (was Re: Installation woes for the average user...)
Date: Thu, 21 May 2009 12:54:07 +0200

Richard Frith-Macdonald wrote:


On 21 May 2009, at 10:34, Wolfgang Lux wrote:

Richard Frith-Macdonald wrote:

Chasing MacOS-X is a problem for us .. sometimes Apple make changes which require ABI changes. Often they add new stuff, which we try to add too. If we don't get the additions quite right in one release, we need to fix them in the next release, and that fix may change the ABI with respect to the new feature, even though the ABI of the main part of the library is stable/ unaffected. This can be something as trivial as implementing an obscure method with an argument of the wrong type (eg a long rather than an int), then having to change the argument type in a later release to match MacOS-X.

I find it quite funny that you regularly bring up Mac OS X compatibility as a reason for ABI breakage. Have you ever looked at what Apple is doing? I can use executables compiled on Mac OS X 10.2 on Mac OS X 10.5 without any problems and Mac OS X does ship with only a single instance of all its libraries/frameworks. I.e., it was possible for Apple to keep the ABI stable and avoid any soname changes for all major libraries since at least 10.2. For sure, they play some tricks here and check at runtime whether an executable was linked against the 10.2, 10.3, 10.4, or 10.5 frameworks and adapt the behavior of some methods accordingly.


Yes, with the manpower they have (and perhaps more importantly, the fact that they control the entire operating system) it's relatively easy to add runtime tricks to pick the behaviors they want.

I don't think that it is *that* difficult. I guess that for determining the OS version an executable was linked on they use features of the mach-o file format, namely that the exact version of a dynamic library is available in the file's header. AFAICT this is not true for the elf format, but one could easily emulate this behavior, e.g., by accompanying each dynamic library with a small object file that exports only the build version of the library and is linked statically with an executable using that library.

Also oftentimes they can just get away with doing things (like the transition from int to NSIntegerbreaking API for 64bit systems) because they simply didn't support things before, so there's no old behavior to be broken.

Wolfgang






reply via email to

[Prev in Thread] Current Thread [Next in Thread]