search

OSGeo / gdal

GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.
https://gdal.org
Other
4.92k stars 2.56k forks source link

Missing DEBUG macro #11311

Open SunBlack opened 1 day ago

SunBlack commented 1 day ago

What is the bug?

Currently we have issues switching from an old GDAL version (3.3.3 - nmake build systems) to a new one (3.5+ - cmake build system) as the linker fails in debug mode. Specifically, we have the linker problem with OGRSpatialReference::FindMatches.

With vcpk, on the other hand, we don't have the linker issue. That's why I used dumpbin to inspect the gdald.lib:

As you can see, the return type differs. The reason for this is this:

#ifdef DEBUG
typedef struct OGRSpatialReferenceHS *OGRSpatialReferenceH;
typedef struct OGRCoordinateTransformationHS *OGRCoordinateTransformationH;
#else
/** Opaque type for a Spatial Reference object */
typedef void *OGRSpatialReferenceH;
/** Opaque type for a coordinate transformation object */
typedef void *OGRCoordinateTransformationH;
#endif

For some reason DEBUG is defined during building self compiled GDAL, but during compiling via vcpkg. Unfortunately, I have not yet found where this macro is defined, as it is not actually a predefined one (_DEBUG is predefined, but not DEBUG, see here). If you create a simple CMake project that has only one executable, set the debug mode in MSVC, and copy in the above #ifdef from GDAL, you will also see that DEBUG is not defined this case.

So the question is: Where is DEBUG defined? And shouldn't it be exported so that it is active for the GDAL headers when it is included?

Steps to reproduce the issue

1) Build GDAL with default settings 2) Create a simple CMake project with just a executable

Versions and provenance

Windows 10/11

Additional context

No response

rouault commented 1 day ago

A workaround is that you use CMake Release or RelWithDebInfo builds, not Debug one

SunBlack commented 9 hours ago

A workaround is that you use CMake Release or RelWithDebInfo builds, not Debug one

Tried it, but doesn't work. When we are building our framework in Debug mode, but using Release GDAL libraries, we are getting SEH expception. When building Release and RelWithDebInfo (with -DCMAKE_RELWITHDEBINFO_POSTFIX=d, so that the two build types do not overwrite each other), CMake sadly prefers the Release library instead the RelWithDebInfo.

rouault commented 9 hours ago

Tried it, but doesn't work. When we are building our framework in Debug mode, but using Release GDAL libraries, we are getting SEH expception.

ah yes, that's a Windows thing where the ABI of the C++ standard library changes between debug and release. Nothing that GDAL can do about.

SunBlack commented 9 hours ago

Tried it, but doesn't work. When we are building our framework in Debug mode, but using Release GDAL libraries, we are getting SEH expception.

ah yes, that's a Windows thing where the ABI of the C++ standard library changes between debug and release. Nothing that GDAL can do about.

Yep. Actually, my idea now is to backport the fix from #11314. So if the version is <= 3.10.0, that it adds the flag to the imported target. However, this would possibly break the vcpkg setup, because for some reason it runs without the flag. That's why I'm currently still looking for what the vcpkg port does differently.

Btw: We need for Linux also a separate Debug build as we compile our framework with _GLIBCXX_DEBUG and therefore also all dependencies needs to be compiled with it (for better assertions). Somehow the missing DEBUG is okay for the linker.

SunBlack commented 8 hours ago

Ok I think I found the reason, why vcpkg works for us. As we are still using GDAL 3.8.5 there, so this commit is still not relevant for us: bfed07022e49b916c842afb591b636397d8f55e0. As vcpkg builds the dependencies the MSVC tree will not be entered (I think). Therefore the Debug-Flag will not be set.

So without testing: Could be it, that OGRSpatialReference::FindMatches is also not working for the vcpkg build 3.9.0 and newer?