Mailinglist Archive: opensuse-factory (710 mails)

[Anders Johansson <ajh@xxxxxxxx>]

On Sunday 12 June 2011 15:29:49 Dave Plater wrote:
> Now go back up the page and look at the part that says "gstreamer doesn't
> quite work 100%".  Can somebody please give me a pointer on how to detect
> ABI differences between library versions. I know how to look for bad
> linking so far, maybe these are just isolated incidents.]

Ideally, the version should just be two numbers. One major version to indicate 
an ABI change, and a minor version to mean a bug fix. The SO-name of the 
library should then just contain the major, not the minor.

ABI changes should be accompanied by a change in SO-name. This is what the 
linker uses to determine if a particular library should be linked with a 
particular binary. The developer should change this when he makes a binary-
incompatible change.

> I've learned the meaning of ABI (application binary interface), it's the 
> address offset (from the base address the binary is loaded into) 
> of the various functions that shared libraries offer to their calling
> programs.

Not entirely. The address offset can change freely. It is the job of the 
linker to determine what it is. The ABI is

* The names of functions
     This is what the linker uses to look it up

* The types and order of parameters to the functions, and the type of the 
return value
     The program just pushes parameters on the stack (or puts them in 
registers) so at runtime there is no way of determining this

* The types and order of members of data structures
   In a compiled program, there is no longer any reference to the names of the 
members, the compiler just translates an access to a structure member into an 
offset, so if this changes there is no way at runtime to correct it

* Types of global variables

* Values of enum and #defined values
   If at compile time the value of HDMI_OUTPUT is 3 for a binary, but a 
library then decides to change that to 4, the binary will do the wrong thing 
at runtime. Again, there is no way at runtime to determine that this has been 
changed, since the compiler just replaces the name with the value

Maybe I've missed something, but broadly speaking this is what makes up the 
ABI, and if any part of this changes in a library, the developer should change 
the SO-name to ensure that a binary that expects the old ABI doesn't get the 
new. It is not trivial to automate this detection. The kernel people have done 
a lot of work on doing this for the kernel, but a general automated solution I 
don't think exists.

Also, this is just for C programs. For C++ or other languages there are other 
aspects. For C++ for example you also have mangling, or how a 
class/object/member/attribute is encoded. It can get quite tricky if you want 
to have a completely automated solution. It is much easier if the developer 
knows what he is doing and changes the SO-name when it needs to be changed

Anders
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx