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.11 02:49 "Re: unintentional ABI change between 3.5 and 3.6?", by Frank Warmerdam
> > 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. Folks, It seems to me that the TIFFDirectory, _TIFFRGBAImage and TIFF structure contents are not intended to be used publically. I am not familiar with what resulted in the TIFFYCbCrToRGB structure change or what it is used for, so I am not clear on whether this is really a change to the public ABI or not. Based on this review, my first concern is that applications running into problems are likely not sticking to the public ABI but are instead dipping into internals. This certainly used to be an enemic problem with the libgeotiff use of libtiff and was responsible for one of the major changes in the 3.6.x series - the move to different handling of tags for custom TIFF extensions. My other reaction to this is that I didn't realize the soname was actually tied to the library version. My understanding was the libtool/shared library versions are generally now not tied directly to the public versions of libraries but instead are otherwise meaningless numbers updated whenever needed. This is the whole -version-info stuff for libtool, right? Perhaps we haven't been doing it that way for libtiff and should. That is, I think the sonames should be decoupled from the published release numbers. All that said, I am not adverse to having the next release of libtiff (based on autoconf/libtool/etc) be called 4.0.0 though there isn't honestly any significant ABI change from 3.6.x or 3.5.x as far as I know. Normally my intention would be to only upgrade the primary version number when a pretty dramatic change is made in the source level interfaces, with the minor release number changing for ABI changes that don't generally require much if any change in application code. Finally, I will return to my first point that I suspect applications are using non-public interfaces and we ought to look at correcting them and improving libtiff so applications can get at what they need via public interfaces if possible. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent