AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2009.05.16 05:38 "[Tiff] Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.16 23:46 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Bob Friesenhahn
2009.05.17 08:51 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.17 09:30 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.17 16:44 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Bob Friesenhahn
2009.05.17 18:02 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Ari Jolma

2009.05.16 23:46 "Re: [Tiff] Potential problem in libtiff when compiled in MinGW", by Bob Friesenhahn

As I've explained in a GDAL bug report http://trac.osgeo.org/gdal/ticket/2649, it is not enough to use WIN32 and _MSC_VER to determine whether to use %I64 instead of %ll as MinGW uses msvcrt.dll but does not define _MSC_VER. This is an issue in several places in libtiff sources (tif_dumpmode.c, tif_luv.c, tif_lzw.c, tif_print.c, tif_read.c, tif_strip.c, and tif_thunder.c).

Have you verified that this is an actual problem? My experience with MinGW builds is that 'long long' works, including in printf type specifications. I am not sure how MinGW accomplishes that but MinGW does provide a thin library which could do transformations if required.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/