LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.07.10 19:07 "Re: unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev
On Sat, Jul 10, 2004 at 05:56:22PM +0000, Jay Berkenbilt wrote: > > 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[3]" 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. Jay, I'm agree that there were changes in the public binary interface (but some of the above mentioned changes are in private interfaces). I think that the best solution will be to issue the final 3.7.0 release as a 4.0.0 and I'm promising to be more carefull with ABI in the future. Frank, any objections against renaming? > 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: You are absolutely right here. That is my fault and I shall try to resolve the problem as soon as possible. But I'm wondering, why I don't have any feedback from the Debian maintainer? Being a Debian user I've looked at the libtiff's bug reports in Debian from time to time and there are bugs, which are certainly should be redirected to upstream, but they are not. At least maintainer may point users to our Bugzilla page. Otherwise bugs stay undiscovered by the library developers. Andrey -- Andrey V. Kiselev Home phone: +7 812 5274898 ICQ# 26871517