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.
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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev