Re: [AD] Re: binary compatibility check

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2006-02-23 at 00:22 -0800, Chris wrote:
> On Wednesday 22 February 2006 23:21, Peter Wang wrote:
> > However, that will still not allow binaries compiled with 4.2.0 to
> > compile with 4.2.1 because the comparison above uses !=, relying on the fact
> > that _get_allegro_version() would mask out the third component of the
> > version number, which it no longer does.  
> 
> That sounds confusing. But If I'm understanding you right, you'saying that 
> programs compiled against 4.2.0 won't /run/ with 4.2.1 because of the != and 
> the changed behavior of that function. The function's behavior can probably 
> change back for now. The only way the 4.2.1 DLL/so would be 
> binary-incompatible with 4.2.0 is due to new functions (any other way would 
> also cause 4.2.1 to be incompatible with 4.2.0 programs). And if that's the 
> case, programs compiled against 4.2.1 won't even be able to start up using 
> 4.2.0, because the DLL/so will be missing functions and'll fail before any of 
> the program is actually run.

Is this really true for DLLs? I only ever got a program to refuse
starting up because of a missing symbol under Unix, never under Windows
(but I don't use Windows a lot, so that doesn't tell terribly much.)

Anyway, I lost track somewhat about this.. so, from the beginning:

header   | library |
4.2.0    | 4.2.0   | -
4.2.1    | 4.2.1   | -
4.2.2    | 4.2.2   | -

4.2.0    | 4.2.1   | MAKE_VERSION is from 4.2.0 and will mask out the
WIP, _get_allegro_version is from 4.2.1, and therefore also should mask
out the WIP. So yeah, I guess we should change it.

4.2.1    | 4.2.0   | This is supposed to always fail. But since we can't
change the 4.2.0 binaries, and they only do the masked out check,
there's nothing we can do to make it fail.

4.2.0    | 4.2.2   | Same as with 4.2.1, we still have to mask out the
version.
4.2.2    | 4.2.0   | Same as with 4.2.1.

4.2.1    | 4.2.2   | This will work, as we mask out the version.
4.2.2    | 4.2.1   | Here, we should be able to find something to make
it fail, I guess..

So, the last case is the one that should be thought about when changing
back _get_allegro_vesion and MAKE_VERSION to mask out the WIP. If we
want it to fail, we could do some sort of extra check there..

> But this'll mean if there's no added functions between 4.2.1 and 4.2.2, then 
> programs for the latter will run with the former. Not a *huge* deal, I 
> suppose.

True. So let's just mask out WIP again, and be done with this :)

> For 4.3, it may be worth it to change this behaviour back to not 
> allowing forwards ABI compatibility at all, though. It's good practice to 
> stay up to date with such libraries, and you wouldn't want to run a program 
> with an older version of a library than it was compiled with anyway. Could 
> also do some sort of compile-time check too, so a program written to use 
> 4.3.1 won't compile with 4.3.0. eg:

Well, 4.3, as an unstable branch, will have neither forward nor backward
compatibility at all, no one ever suggested anything else, unless I'm
confusing something now.

For 4.4, things will be different again of course. From a developers
view, I'd like also 4.4 to have no forward compatibility, but I can see
the reason for wanting it. Assume, there's a binary linux distribution,
and they have lots of games compiled against Allegro 4.4.0. Now Allegro
4.4.1 comes out. If there's forward compatibility, they can update the
allegro-4.4 package to 4.4.1 the next day, since the 4.4.0 games will
still work. Otherwise, they would need to make an allegro-4.4.1 package,
make new packages of all games depending on the new allegro-4.4.1, and
so on.. so in short, we need forwards compatibility.

> #define AL_USE_VERSION(4, 3, 4)
> #include <allegro/allegro.h> // will #error if the header is 4.3.3 or earlier
> 

That's a good idea in any case, saves users the compilation, just to
fail at runtime later..

-- 
Elias Pschernig