<div dir="ltr"><div><br><br>On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:<br>><br>> > Stupid question: such a #define has only effect on compile time. If GDAL<br>><br>> > has been compiled without HAVE_LONG_LONG being defined, and then we define<br>><br>> > HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess?<br>><br>>  <br>><br>> With MSVC, GIntBig expands to __int64 , which is equivalent in practice to long long.<br><br>MinGW also has __int64, therefore it would be great if you could apply<br><br>--><br>Index: port/cpl_port.h<br>===================================================================<br>--- port/cpl_port.h    (revision 40701)<br>+++ port/cpl_port.h    (working copy)<br>@@ -219,7 +219,7 @@<br> /*      64bit support                                                   */<br> /* -------------------------------------------------------------------- */<br> <br>-#if defined(WIN32) && defined(_MSC_VER)<br>+#if (defined(WIN32) && defined(_MSC_VER)) || defined(_WIN32)<br> <br> #define VSI_LARGE_API_SUPPORTED<br> typedef __int64          GIntBig;<br><--<br><br>to gdal-trunk<br><br>Apart from that, GDALSetCacheMax[64](bytes) could be replaced with CPLSetConfigOption( "GDAL_CACHEMAX", "MB" ), that should avoid the issues with GIntBig on MS Windows.<br><br></div>Markus M<br><br></div>