Option /MD is for linking against release runtime. If set this way, the preprocessor definition _DEBUG (/D_DEBUG) must not be set also.

In consequence, runtime debug reports are not available anymore (_CrtDbgReport, _CrtDbgReportW, http://msdn.microsoft.com/en-us/library/8hyw4sy7(VS.80).aspx)

Result of some tests:

• ITK compiles well with CMAKE_CXX_FLAGS_DEBUG: /MD /Zi /Ob0 /Od /RTC1
• VTK compiles well, also

• Open-Source MITK has a build system issue related to POCO:

POCO uses the CMAKE_DEBUG_POSTFIX ("d"), but if _DEBUG is not set anymore, libnames are the same for debug and release, but target_link_libraries(...) is set up with this "d" as postfix.

• all our internal sources compile well. Debugging speed is indeed drastically improved.

Mixing of runtimes may cause heap corruption:

Each copy of the CRT library has a separate and distinct state. As such, CRT objects such as file handles, environment variables, and locales are only valid for the copy of the CRT where these objects are allocated or set. When a DLL and its users use different copies of the CRT library, you cannot pass these CRT objects across the DLL boundary and expect them to be picked up correctly on the other side.

Also, because each copy of the CRT library has its own heap manager, allocating memory in one CRT library and passing the pointer across a DLL boundary to be freed by a different copy of the CRT library is a potential cause for heap corruption.

(http://msdn.microsoft.com/en-us/library/ms235460.aspx)

[SVN revision 26110]
ENH (#5281): disable POCO Flag _DEBUG, add POCO_NO_AUTOMIC_LIBS instead. This will allow for successfully compiling Poco against release runtimes (also as debug targets)

[SVN revision 26116]
COMP (#5281): revert

[SVN revision 26117]
COMP (#5281): disable POCO Flag _DEBUG, add POCO_NO_AUTOMIC_LIBS instead. This will allow for successfully compiling Poco against release runtimes (also as debug targets)

POCO_NO_AUTOMIC_LIBS defined works well to build POCO, but all Libs using POCO require also this define to be set (if we want to avoid any changes to the POCO sources).

Any comments, where this define is made best?

This should be done in a generated header file which is then included by all poco headers. Maybe there is already some central poco include? Sascha?

I don't know if there is a Poco header which is included by every other Poco file. If yes, we could do as Marco suggested. But please create a patch for the Poco modifications and check it in to subversion under Utilities/Poco/Patches/

Second option would be to add "-DPOCO_NO_AUTOMIC_LIBS" to CMAKE_CXX_FLAGS in MITKs (and every project depending on MITK) global CMakeLists.txt file.

Yes, removing the hard-coded /D_DEBUG in Poco's Cmake code makes makes it possible to link against Release-CRTs.

However, MITK, and all POCO-using derivates rquire POC_NO_AUTOMATIC_LIBS to be set manually as flag.

Close this bug?

[SVN revision 26139]
FIX (#5281): add the _DEBUG flag hardcoded for all compiles besides MSVC.

org.blueberry.osgi.tests fails on gcc if this flag is not set.

Side-effect:

A successfully compiled ExtApp (Debug) and linked to release-CRTs fails to load plugins. Poco is looking for the release-named ones without 'd' suffix.

Thus, this option is currently limited to non-blueberry apps.

FAZIT of evaluation:

• compiling debug libs by linking against MSVC-Multithreaded-Release-DLLs (/MD) works, speed increase may vary w.r.t. usage of runtime lib functions

• ALL toolkits and other target link libraries must be linked consistently against the same type runtimes. Dependency Walker may help to detect mixed miss-configurations

• As _DEBUG is not defined anymore, debugging may behave somehow different

• POCO does compile also. HOWEVER, Blueberry/POCO-OSGI like applications have runtime issues as they look for 'release-named' DLLs.