#3346 closed defect (fixed)
Debug build of static library crashes on Windows
Reported by: | Mateusz Łoskot | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | ConfigBuild | Version: | svn-trunk |
Severity: | normal | Keywords: | msvc, debug, release, static, gdal.lib |
Cc: |
Description
It is a well-known issue that GDAL forces to link against /MD in nmake.opt CRT - Dynamic Link for Release configuration when building using Visual C++ compiler in debug mode:
nmake /f makefile.vc DEBUG=1
If user wants to link his application against GDAL static library (gdal.lib) and build be able to debug his application, what means linking against /MDd, then he should expect crashes, heap corruption and other serious problems. Shortly, the use of /MD effectively removes possibility to properly debug clients' programs.
In spite of what has been said and discussed so far, I think that use of /MD is a bad idea. This mechanism is consistent on Windows and it assumes that if software is compiled in Debug configuration, it happens on developer's environment, not on end-user's machine and all related components, especially those used in form of static library, are built in Debug configuration and linked against /MDd.
GDAL default settings are completely exotic here and ignore the recommendations for development in Windows environment. Thus, it is GDAL problem.
Other related tickets: #540, #850, #1647
References:
Change History (5)
comment:1 by , 12 years ago
comment:4 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I opened this ticket to provoke some debate on that issue and collect all the details in one place. However, AFAIR, GDAL links against /MD instead of /MDd by design, and given 5 years without any changing decisions, the ticket can be closed as wontfix.
I'm closing it.
Related ticket Debug version of app with GDAL lib - linker problem - ITERATOR_DEBUG_LEVEL