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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org