Re: [AD] Re: binary compatibility check

[Chris <chris.kcat@xxxxxxxxxx>]

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.

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

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