Even Rouault <[email protected]> writes: > That's what we do already what we do for a few functions (like fopen64 > vs fopen): cf > https://github.com/OSGeo/gdal/blob/1e3cc18e298e81c1f42162b10ef7beb0dd94d3cf/cmake/helpers/configure.cmake#L230 > > But for some reason, in that circumstance, it seems it detects symbols > that are not available afterwards at build time. It might be related > to the warning at bottom of > https://cmake.org/cmake/help/latest/module/CheckFunctionExists.html > about prefering check_symbol_exists() rather than > check_function_exists(). I suspect that the xxx64 symbols are > available in a system library but require special #define to be > usable.
I see - so the compilation can throw an "implicit definition" warning and succeed, and this means that if the symbol resolves at link time, the test passes, even if the function signature is totally non-matching. That sounds like a buggy implementation of Check_Function_Exists, but maybe that's what autoconf does. Requiring warning-clean compilation probably has its own issues. Looking at CheckSymbolExists, it seems to check the right things, so perhaps nik@ can try changing to that and see what happens.
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
