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.14 16:11 "Re: unintentional ABI change between 3.5 and 3.6?", by Jay Berkenbilt
This thread seems to have stopped before any real resolution was reached. Since I flip-flopped back and forth several times, I'll summarize my eventual conclusions so we can see whether there's consensus. ------- EXECUTIVE SUMMARY: There are incompatible ABI changes, so the next version of the shared library needs to be 4.0.0. The decision about whether to make the next version of the software 4.0.0 or not also needs to be made, though it is a different decision. Some resolution on whether strong isolation of TIFFRGBAImage (and other structs?) should also be made. ------- Between 3.5.7 and 3.6.1, there were changes to struct _TIFFRGBAImage which affected its size among other things. As a result, any application that uses TIFFRGBAImage (which is typedefed to struct _TIFFRGBAImage) that was compiled against 3.5.7 and runs against the shared library with 3.6.1 (or vice versa) will fail to work properly and possibly have a segmentation fault. Since TIFFRGBAImage is not an incomplete type and since an instance of TIFFRGBAImage can be instantiated on the stack and have a pointer to it passed to functions such as TIFFRGBAImageBegin, TIFFRGBAImageGet, etc., it seems clear now that this does constitute an accidental ABI change that affects the documented public interface. (I haven't studied whether the other changes are ABI changes since one is all we need.) Therefore, the next release of libtiff should have a new soname, most likely 4.0.0 (though some have suggested skipping some numbers). This should happen regardless of what the next version of libtiff is. It may be desirable to keep the source version at 3.7.0 since there are no source level interface changes. In any case, there seems to be consensus that the soname should be decoupled from the library version number. On the other hand, to protect against this kind of thing from happening again and to make the public interface more robust against changes to structures, TIFFRGBAImage could be changed to an incomplete type. For this to work, there would need to be library-based allocators and deallocators for these, and people would only be able to declare TIFFRGBAImage* in their code (like TIFF). This would be a source-level interface change and would certainly warrant moving the version of the software to 4.0.0. If this is done, I think it would make sense to take a careful look at tiffio.h and see what other structures, if any, should be made into incomplete types. Other considerations: the next version has a new build system, and may also include LZW support. (This also seems unresolved.) These could justify moving to 4.0.0 for psychological reasons even if there were no source level interface changes. Do the libtiff developers agree with this analysis? If not, in what ways do you disagree? I've suggested more than one potential fix (a trivial one of just changing the soname, and a more complex one of changing TIFFRGBAImage). If both are desirable but we don't want to hold up a release for the second, that just means there's another soname change coming up, which doesn't seem like a big deal. (I have no idea how soon a new release is coming out.) On the Debian side, many things including GTK+ and GNOME have been rebuilt with 3.6.1 already, so I've suggested to the libtiff debian maintainer that 3.6.1 be the official libtiff.so.3 and that future bugs resulting from this problem be resolved by rebuilding the application with 3.6.1. (Basic rationalization: upstream maintainers recognize the need for a new soname, so this is a one-time problem, and right now, there are more applications working with 3.6.1 than working with 3.5.7. Therefore, the easiest fix is just to let 3.6.1 be the final "3" version.) This suggestion has not yet been acknowledged. I'll push it some more after we reach consensus here. :-) Thanks for wading through my long, wordy message. -- Jay Berkenbilt <ejb@ql.org> http://www.ql.org/q/