[gdal-dev] 'HOST_FILLORDER': macro redefinition

[Paul Meems]

Thanks Even for the clarification.
We'll add the #undef.

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/20190716/33347ff1/attachment.html>