<div dir="ltr">Hi Even,<div><br></div><div>I come across other macro redefinitions:</div><div><ul><li><span style="color:rgb(23,43,77);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:1em;font-variant-numeric:normal;font-variant-east-asian:normal;letter-spacing:0em;line-height:1.714;white-space:pre-wrap">'TIFF_INT64_T': macro redefinition (compiling source file Control\Map_Core.cpp) \gdal_sdk\v141\include\win32\tif_config.h 39 </span></li><li><span style="color:rgb(23,43,77);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:1em;font-variant-numeric:normal;font-variant-east-asian:normal;letter-spacing:0em;line-height:1.714;white-space:pre-wrap">'TIFF_UINT64_T': macro redefinition (compiling source file Control\Map_Core.cpp) \gdal_sdk\v141\include\win32\tif_config.h 45</span></li></ul></div><div><span style="color:rgb(23,43,77);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:1em;font-variant-numeric:normal;font-variant-east-asian:normal;letter-spacing:0em;line-height:1.714;white-space:pre-wrap"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small;white-space:normal">TIFF_INT64_T is defined differently in these files:</span>
</span></div><div> \GDAL_SDK\v141\include\win32\tif_config.h(39):#define TIFF_INT64_T signed __int64<br> \GDAL_SDK\v141\include\win32\tiff.h(77):typedef TIFF_INT64_T int64;<br> \GDAL_SDK\v141\include\win32\tiffconf.h(17):#define TIFF_INT64_T signed long long<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">And
TIFF_UINT64_T as well: <br> \GDAL_SDK\v141\include\win32\tif_config.h(45):#define TIFF_UINT64_T unsigned __int64<br> \GDAL_SDK\v141\include\win32\tiff.h(78):typedef TIFF_UINT64_T uint64;<br> \GDAL_SDK\v141\include\win32\tiffconf.h(29):#define TIFF_UINT64_T unsigned long long<br><br>Is this related to your merge request #87 and will it also be solved when Tamas (<a href="http://gisinternals.com">gisinternals.com</a>) generates new files or is this a separate problem?</div><div><br></div><div>And for now can we solve it by #undef the macros?</div><div dir="ltr"><br></div><div dir="ltr">Regards,<br><br>Paul<br>
</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op ma 15 jul. 2019 om 12:24 schreef Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If it were redefining to the same value, that would be one thing, but since<br>
> it is redefining to another value, it makes you wonder 1) why is it coming<br>
> in differently, and 2) which value should it be?<br>
<br>
Paul, overall this doesn't seem critical as the only real use of <br>
HOST_FILLORDER in all GDAL, libtiff and libgeotiff code bases in in libtiff <br>
TIFFOpen() function when the esoteric 'H' open flag is used, and that one is <br>
likely rarely used (not used by GDAL typically). So you could just #undef <br>
HOST_FILLORDER between the 2 #include to silence the warning.<br>
<br>
Tamas, how is tiffconf.h in gisinternals produced, which has this unexpected <br>
#define HOST_FILLORDER FILLORDER_MSB2LSB (should be LSB2MSB for Intel <br>
platforms) ? Is this the result of cmake ? I guess so, as it doesn't seem to <br>
be in sync with the tiffconf.vc.h that is also provided and used by nmake <br>
builds. That would mean that there's an issue in the CMake configuration step <br>
with VS builds:<br>
<a href="https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L394" rel="noreferrer" target="_blank">https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L394</a><br>
<br>
Actually, I just found a CI with CMake + Windows at<br>
<a href="https://ci.appveyor.com/project/rleigh-codelibre/libtiff-didfs/builds/25846668/job/ory5w098j8wcij9x" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/rleigh-codelibre/libtiff-didfs/builds/<br>
25846668/job/ory5w098j8wcij9x</a><br>
where I can see:<br>
<br>
[00:02:58] -- CMAKE_HOST_SYSTEM_PROCESSOR set to AMD64<br>
[00:02:58] -- HOST_FILLORDER set to FILLORDER_MSB2LSB<br>
<br>
So this seems to be a case sensitivity issue when comparing AMD64 vs amd64.<br>
I've just submitted<br>
<a href="https://gitlab.com/libtiff/libtiff/merge_requests/87" rel="noreferrer" target="_blank">https://gitlab.com/libtiff/libtiff/merge_requests/87</a><br>
to fix this.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>