Francois Gouget <fgou...@free.fr> wrote: > The amd64 version conflicts with the i386 one which makes it > impossible to install both. As a result the > /usr/lib/i386-linux-gnu/libtiff.so symbolic link is missing so that > developping 32bit applications using this library is impossible on a > 64bit system. > > Furthermore this development package does not seem to be multiarch > aware as there is no Multi-Arch field. > > My understanding is that as long as there are no > architecture-dependent headers there is no obstacle (i.e. no toolchain > issue) to tagging the development package as 'Multi-Arch: same'. The > symbolic link (and any static libraries) should be no issue as they > are already in the architecture-qualified folders.
Unfortunately, libtiff-dev does actually contain an architecture-dependent header file, so Multi-Arch: same would not be appropriate. If you extract and diff the i386 and amd64 versions of libtiff5-dev, you will notice that tiffconf.h contains architecture-dependent definitions of TIFF_INT64_T and TIFF_UINT64_T. For libtiff4-dev, tiffconf.h contains a definition of SIZEOF_LONG. Both of these architecture-dependencies could be avoided by upstream, but they are there, so I can't use 'Multi-Arch: same'. I'm not sure whether there is some other way to handle this right now other than to patch. In the libtiff4-dev case, the code should just use sizeof long rather than defining its value (though maybe there are static definitions of things to be a certain size -- the code would have to be inspected). For libtiff5, we could patch so that we use stdint.h (which doesn't exist everywhere libtiff works but does on all debian platforms) and define TIFF_*INT64_T in terms of int64_t and uint64_t, but this requires a bigger change than just editing debian/control. -- Jay Berkenbilt <q...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
