[gdal-dev] 'HOST_FILLORDER': macro redefinition

[Paul Meems]

Hi Even,

I come across other macro redefinitions:

   - 'TIFF_INT64_T': macro redefinition (compiling source file
   Control\Map_Core.cpp) \gdal_sdk\v141\include\win32\tif_config.h 39
   - 'TIFF_UINT64_T': macro redefinition (compiling source file
   Control\Map_Core.cpp) \gdal_sdk\v141\include\win32\tif_config.h 45

TIFF_INT64_T is defined differently in these files:
  \GDAL_SDK\v141\include\win32\tif_config.h(39):#define TIFF_INT64_T signed
__int64
  \GDAL_SDK\v141\include\win32\tiff.h(77):typedef TIFF_INT64_T  int64;
  \GDAL_SDK\v141\include\win32\tiffconf.h(17):#define TIFF_INT64_T signed
long long

And  TIFF_UINT64_T  as well:
  \GDAL_SDK\v141\include\win32\tif_config.h(45):#define TIFF_UINT64_T
unsigned __int64
  \GDAL_SDK\v141\include\win32\tiff.h(78):typedef TIFF_UINT64_T uint64;
  \GDAL_SDK\v141\include\win32\tiffconf.h(29):#define TIFF_UINT64_T
unsigned long long

Is this related to your merge request #87 and will it also be solved when
Tamas (gisinternals.com) generates new files or is this a separate problem?

And for now can we solve it by #undef the macros?

Regards,

Paul


Op ma 15 jul. 2019 om 12:24 schreef Even Rouault <even.rouault at spatialys.com
>:

> > If it were redefining to the same value, that would be one thing, but
> since
> > it is redefining to another value, it makes you wonder 1) why is it
> coming
> > in differently, and 2) which value should it be?
>
> Paul, overall this doesn't seem critical as the only real use of
> HOST_FILLORDER in all GDAL, libtiff and libgeotiff code bases in in
> libtiff
> TIFFOpen() function when the esoteric 'H' open flag is used, and that one
> is
> likely rarely used (not used by GDAL typically). So you could just #undef
> HOST_FILLORDER between the 2 #include to silence the warning.
>
> Tamas, how is tiffconf.h in gisinternals produced, which has this
> unexpected
> #define HOST_FILLORDER FILLORDER_MSB2LSB (should be LSB2MSB for Intel
> platforms) ? Is this the result of cmake ? I guess so, as it doesn't seem
> to
> be in sync with the tiffconf.vc.h that is also provided and used by nmake
> builds. That would mean that there's an issue in the CMake configuration
> step
> with VS builds:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L394
>
> Actually, I just found a CI with CMake + Windows at
> https://ci.appveyor.com/project/rleigh-codelibre/libtiff-didfs/builds/
> 25846668/job/ory5w098j8wcij9x
> <https://ci.appveyor.com/project/rleigh-codelibre/libtiff-didfs/builds/25846668/job/ory5w098j8wcij9x>
> where I can see:
>
> [00:02:58] -- CMAKE_HOST_SYSTEM_PROCESSOR set to AMD64
> [00:02:58] -- HOST_FILLORDER set to FILLORDER_MSB2LSB
>
> So this seems to be a case sensitivity issue when comparing AMD64 vs amd64.
> I've just submitted
> https://gitlab.com/libtiff/libtiff/merge_requests/87
> to fix this.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190802/035cf3df/attachment.html>