2004.07.10 17:56 "[Tiff] unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
I apologize if this has already been discussed, but my searches of the archives have not turned anything up, and I can't find evidence of a formal bug tracking system to search. If I've missed something, a pointer would be appreciated.
There is a problem in Debian right now with several applications that were built against libtiff 3.5.7 no longer working correctly when run with the 3.6.1 dynamic library. Since both libraries are libtiff.so.3, they should be compatible. In all cases, rebuilding with 3.6.1 "fixes" the problem. To me (and others), this suggests a non-compatible ABI change not accompanied by an soname change.
This analysis was posted by Petter Reinholdtsen <email@example.com> in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236247:
> Looking at the difference in the header files in version 3.5.7 and > version 3.6.1, there seem to be changes to several structs and types.
> TIFFDirectory in tif_dir.h lost member td_software and got a new
> members td_xmlpacketLength, td_xmlpacketData,
> td_customValueCount and td_customValues.
> TIFFYCbCrToRGB in tiffio.h changed type and name of the last member
> "float coeffs" to "int32* Y_tab".
> struct _TIFFRGBAImage in tiffio.h got new members req_orientation
> and cielab.
> struct tiff in tiffiop.h got new members tif_dirlist, tif_dirnumber,
> tif_decodestatus, tif_encodestatus, tif_tagmethods and
> tif_clientinfo, and lost members tif_clientdir,
> tif_vsetfield and tif_vgetfield.
> I might have missed some types, structs and headers. I have no idea
> if these structs are part of the public ABI for the library, but > suspect that they are, and that the lbirary need a new soname.
I haven't looked into the problem deeply myself, but it's clear that, whether this analysis is accurate or not, we do have a problem of shared library incompatibility. If this is the case, it seems that we're in a bit of a pickle here. As I see it, there are two possible resolutions, both of which are somewhat undesirable:
- Adjust the ABI to restore compatibility with older versions, and make 3.6.1 an anomaly.
- Update the soname. But would you then want to call 3.7.0 4.0.0 instead? Either that, or the soname would have to be divorced from the major version number.
It seems to me that, if there is a "contract" that says that there should be no non-compatible ABI changes within the same major version, then that contract has been accidentally broken. If there is no such guarantee, then the soname in the shared library should certainly be changed every time a non-compatible change is made.
Thoughts? Do you agree that it's a mistake to create a situation where an application compiled with 3.5.7 doesn't run with 3.6.1's shared library? (If not, then I must be misunderstanding something and would appreciate an explanation.) Do you acknowledge that this situation has happened? If not, I'll try to dig deeper. There are many examples of this situation in Debian as you can see from the following link:
Thanks! As a regular user and big fan of libtiff, I'm eager to see this resolved and am happy to help out in any way I can.
Jay Berkenbilt <firstname.lastname@example.org>