Arch Linux

Description:

Type TIFF_(U)INT64_T is based on long in lib32-gdk-pixbuf2 but is defined as long long in lib32-libtiff. This breaks software that relies on the consistency of these types between both packages, for example when using GdkPixbufLoader to load TIFF files.

In general, /usr/include/tiffconf.h from package libtiff will differ on i686 and x86_64 systems. Definition of TIFF_(U)INT64_T will use long on x86_64 but long long on i686.
io-tiff.c includes this system header file via line

#include <tiffio.h>

That is the x86_64 specific headers are included here whereas lib32-libtiff will generate its own i686-compatible tiffconf.h from tiffconf.h.in using configure.


Additional info:

* package version: 2.31.3-1
* lib32-libtiff version: 4.0.3-2
* gcc version: 4.9.2-4
* system architecture: AMD64

* gdb output when debugging the attached program with debug enabled versions of lib32-libtiff and lib32-gdk-pixbuf2:

(gdb) info types uint64
All types matching regular expression "uint64":

File /usr/include/stdint.h:
typedef unsigned long long uint64_t;

File /usr/include/tiff.h:
typedef unsigned long uint64;

File /usr/lib32/glib-2.0/include/glibconfig.h:
typedef unsigned long long guint64;

File tiff.h:
typedef unsigned long long uint64;


Steps to reproduce:

Create the attached pixbufloader program on x86_64 using the given Makefile and compare output of

pixbufloader initgraph.tif
pixbufloader32 initgraph.tif

In general, the program should work on any system architecture when compiled with march=native whereas the multilib version fails due to type inconsistencies.


Possible solution:

* libtiff upstream could switch to using stdint.h for type definitions. They will argue that their current system of generating tiffconf.h using configure works on any given system.
* lib32-gdk-pixbuf2 could patch io-tiff.c to include a patched version of /usr/include/tiffconf.h before tiffio.h which defines types such as TIFF_(U)INT64_T on the basis of stdint.h.