Post by Tamas Szekeres
Looks like I've missed this thread earlier, but according to this change we
might either compile all the dependent libraries for /MDd (at least for the
statically linked libraries) or we trust in that GDAL is safe to compile
against a different CRT than the dependencies. That means that GDAL won't
free up memory that have been allocated in either of the dependencies or
vica versa. I'm not completely sure if the latter applies.
The earlier approach was a bit more like the RelWithDebInfo setting in the
cmake terminology which is not considered as a wrong setting, but that has
it's own purpose. At the moment I'm not aware of any binary distributions
or SDKs out of the box which would be compatible with the /MDd setting,
that causes that DEBUG=1 has a fairly limited usability from now on.
I guess the people who complained did builds with none or little
Perhaps adding a RELWITHDEBINFO=1 flag that would expand to
OPTFLAGS= $(CXX_ANALYZE_FLAGS) $(CXX_PDB_FLAGS) /nologo /MP /MD /EHsc /FC /
D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DDEBUG
(ie same as default build but without /Ox and with /DDEBUG)
would help ?
That would not be equivalent to CMake RelWithDebugInfo, which is is pretty
self-descriptive. Here is explanation from
"The difference between Debug and RelwithDebInfo is that RelwithDebInfo is
quite similar to Release mode. It produces fully optimised code, but also
builds the program database, and inserts debug line information..."
Or, I'm m being unclear about use of /DEBUG