Re: [AD] Re: binary compatibility check

[Chris <chris.kcat@xxxxxxxxxx>]

On Friday 24 February 2006 03:39, Elias Pschernig wrote:
> So basically, we shouldn't break binary compatibility on minor version
> (like 4.4 -> 4.5) changes?

Right, unless it needs to be broken (eg. a struct size that compiled programs 
access changes size). By the same token, you could break compatibility 
between 4.4.4 and 4.4.5 if you wanted (not that we would or should, just that 
we could). The idea is to keep ABI breakage down to a minimum. By making the 
"version" on the library name independant of the actual library version, the 
only libname-enforced breakage would be whenever that number is decided to be 
bumped, which should only be when backwards binary compatibility needs to be 
broken.

Here's a short example:
* User installs Allegro 4.4.0 (which has liballeg-0.so).
* User installs a program that uses Allegro 4.4.0 (and thus relies on 
liballeg-0.so).
* Allegro backwards binary compatibility is intentially broken in 4.4.5, 
bumping the libname to liballeg-1.so.
* User installs 4.4.5.
* Now, when the user tries to run the program, it'll either find the previous 
liballeg-0.so (assuming he left it on the system) and happily run, or it'll 
complain that liballeg-0.so isn't found because it was deleted and abort. In 
the latter case, all the user would need to do is drop the latest version of 
liballeg-0.so (which the program works with) in the library path.

In Unix, I think this kind of thing is done with having a symlink called 
libfoo.so.0 point to the latest library that'll work with programs that need 
arbitrary-version-0 (eg. liballeg.so.0 -> liballeg-4.4.0.so). Allegro already 
does something like this:

$ ll liballeg*
-rwxr-xr-x  1 root root 840K Feb 17 16:07 liballeg-4.2.1.so
lrwxrwxrwx  1 root root   17 Feb 21 13:31 liballeg.so.4.2 -> liballeg-4.2.1.so
-rw-r--r--  1 root root 171K Feb 17 16:07 liballeg_unsharable.a

But it uses the actual library version, which means it implicitly breaks when 
the major or minor version number changes, regardless if ABI was actually 
broken. If the file's version number was independant of the library version 
number, this implict break wouldn't occur. Instead, the name-enforced break 
could be controlled by only changing the number when the devs saw fit (which 
would be when backwards binary compatibility is broken).