AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2004.07.10 17:56 "unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.10 19:07 "Re: unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev
2004.07.10 19:56 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.11 02:49 "Re: unintentional ABI change between 3.5 and 3.6?", by Frank Warmerdam
2004.07.11 14:27 "Re: unintentional ABI change between 3.5 and 3.6?", by Bob Friesenhahn
2004.07.11 17:32 "Re: unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev
2004.07.11 18:05 "Re: unintentional ABI change between 3.5 and 3.6?", by Bob Friesenhahn
2004.07.11 16:47 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.11 17:27 "Re: unintentional ABI change between 3.5 and 3.6?", by Andrey Kiselev
2004.07.11 17:52 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.11 17:56 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.14 16:11 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
2004.07.14 16:50 "Re: unintentional ABI change between 3.5 and 3.6?", by Bob Friesenhahn

2004.07.10 17:56 "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 <pere@hungry.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[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.

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:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=libtiff3g&archive=no

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 <ejb@ql.org>
http://www.ql.org/q/
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff