Bug#735847: freeimage: builds wrong tiff, broken 32 bit
On Sun, Jan 19, 2014 at 8:18 PM, Julian Taylor
<jtaylor.debian@googlemail.com> wrote:
> I disagree, all three issues found do seem like independent issues with
> little relation (on amd64 at least).
Ok, so there are three bugs:
1)
> the exif tag truncation is very unlikely cause the complete data
> structure corruption.
Ah, Sources/LibTIFF4 instead of LibTIFF on the lines that updated the
sources. Thanks for finding that (gensrclist.sh, genfipsrclist.sh)
2) [patch is available]
> tag truncation
3)
> The wrong type sizes can not be related because I tested that and it
> only affects 32 bit (which I was not using for debugging).
On bug #3, it looks like Source/LibTIFF/ is configured at build time,
but Source/LibTIFF4/ has already been configured and shipped by
upstream.
This is extra confusing, because upstream's tiffconf.h in SVN doesn't
match what they are distributing in their source tarballs:
http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/LibTIFF4/tiffconf.h?view=markup
At no point in the history did tiffconf.h match what they are distributing.
Also, this has been reported before:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601762
And fixed with these two patches
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=5657e6b0bbc7def9e5598e6872a91a202b7b4113
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=cddd3e04b65efb1291ed6b28ac8310f33eec4466
namely
+/* Signed 64-bit type formatter */
+#define TIFF_INT64_FORMAT "%" PRId64
+
+/* Signed 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_INT64_T signed long
+#else
+#define TIFF_INT64_T signed long long
+#endif
+
+/* Unsigned 64-bit type formatter */
+#define TIFF_UINT64_FORMAT "%" PRIu64
+
+/* Unsigned 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_UINT64_T unsigned long
+#else
+#define TIFF_UINT64_T unsigned long long
+#endif
I'll go ahead and ask upstream if they could reconsider allowing their
packages to build using system libraries, these are all things best
handled by (and probably already solved by) libtiff maintainers.
Thanks again,
Scott
Reply to: