[gdal-dev] /MD vs /MDd for DEBUG MSVC builds

Mateusz Loskot mateusz at loskot.net
Mon Oct 16 14:48:07 PDT 2017


On 16 Oct 2017 11:20 pm, "Even Rouault" <even.rouault at spatialys.com> wrote:

On lundi 16 octobre 2017 23:01:52 CEST Tamas Szekeres wrote:
> 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.
>

Ah Windows...

I guess the people who complained did builds with none or little
dependencies.

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
https://cmake.org/pipermail/cmake/2001-October/002479.html


"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

Mateusz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171016/e55fa580/attachment-0001.html>


More information about the gdal-dev mailing list