LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 2008
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
2008.06.17 22:38 "Re: ... a year with no release (?)", by Jay Berkenbilt
[Joris: please note: the ABI fix you made in August 2007 was not committed to the 3.9 branch.] Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote: >> If 3.9 were released and demonstrated to be binary compatible with >> 3.8.2 within the next week or so, it could be part of the next debian >> release. The freeze for libraries with reverse dependencies is fast > > I don't believe that it is binary compatible. If it was, then it > would have been called 3.8.3. :-) Actually, all the 3.x releases in recent memory (at least since 2004) have been binary compatible except for an accidental binary incompatibility introduced in 3.6.1, which is the reason that debian, cygwin, and some others use a different shared library soname from the libtiff distribution and why 4.0.0 will create libtiff.so.5. There was a small incompatibility accidentally introduced in the short-lived 3.8.0 release that was fixed in 3.8.1. I reported a binary incompatibility in 3.9.0 beta, a fix to which was committed by Joris shortly afterward (though I see it was not committed on the 3.9 branch -- see revision 1.79 of Tiffi.h). I believe the intention is that all the 3.x versions should be have binary backward compatibility in that an application linked with 3.8.2 should work with the 3.9.0 shared libraries. I have a series of tests that I run on every release to verify this before uploading to debian. So, at the moment, 3.9.0 is not binary compatible with 3.8.2 and is therefore, in my opinion, not ready for release. However, if Joris committed the changes he made along with revision 1.79 to tiffio.h to the 3.9 branch, it might be ready to go. Then again, I'm not involved with the sources other than in this small way, so I can't possibly make that call. :-) I can definitely promise that 3.9.0 will not make it into debian unless it is binary compatible with 3.8.2 though. Joris, maybe you can address this? The original email on this is referenced below. I see other changes in the 3.9 branch to the _TIFFRGBAImage structure: uint8* UaToAa; /* Unassociated alpha to associated alpha convertion LUT */ uint8* Bitdepth16To8; /* LUT for conversion from 16bit to 8bit values */ which were not fixed in the 1.79 commit. --Jay -------------------------------- To: "Andrey Kiselev" <dron@ak4719.spb.edu>, "Jay Berkenbilt" <ejb@ql.org> Subject: Re: [Tiff] possible ABI change in 3.9.0 beta? Date: Fri, 10 Aug 2007 12:20:13 +0200 Andrey, Andrey Kiselev wrote: > On Sun, Jul 22, 2007 at 11:58:25AM -0400, Jay Berkenbilt wrote: > > I was looking at the changes from 3.8.2 to 3.9.0 beta, doing my > > usual inspection for possible ABI changes. I notice that > > _TIFFRGBAImage has added two new fields: > > > > uint16 SubsamplingHor; /* subsampling factors */ > > uint16 SubsamplingVer; > > > > Does this mean that there has been an accidental ABI change between > > 3.8.2 and 3.9.0? If so, is it a problem that can be fixed before > > 3.9.0? > > Oops. That stuff should be kept intact. > > Joris, could you look into this problem? I presume it was you who > added these fields. Is it possible to not touch that public structure? Fixed. Best regards, Joris --Jay