Not only is it possible ... it WILL happen if you use the Microsoft C++ compiler and try to mix and match Release and Debug compilation units.
The MS compiler has some very nice memory tracking facilities built into the Debug runtime libraries, but it is accomplished via different structs for Debug and Release builds with extra stuff in the Debug structs. So allocations from a Debug compilation unit will not be accessed correctly in a linked-in Release compilation unit when a pointer to it is passed across the boundary. You will see access violations and hard crashes happening in builds from the Microsoft compiler unless you ensure that everything in a build has matching Debug/Release defines and compiler settings. It is only safe to mix-n-match if all calls which cross a boundary between compilation units have NO differences in their struct and class definitions from an ABI perspective. Since it is difficult to verify when this is the case (in general) for large C++ projects, it's best to avoid mixing and matching... HTH, David C. On Wed, Dec 23, 2015 at 8:29 AM, Ruslan Baratov via CMake <cmake@cmake.org> wrote: > On 22-Dec-15 04:07, Magnus Therning wrote: >> >> Ruslan Baratov writes: >> >>> On 20-Dec-15 01:31, Magnus Therning wrote: >>>> >>>> Ruslan Baratov writes: >>>> >>>>> How about using RelWithDebInfo? See: >>>>> http://stackoverflow.com/a/28124715/2288008 >>>> >>>> Hmm, I'm probably missing something but how does that solve the issue >>>> with some targets requiring NDEBUG to be *undefined* and other targets >>>> requiring NDEBUG to be defined? >>> >>> I don't think that building targets with different NDEBUG values is a >>> good idea. More correct approach will be to introduce custom macro to >>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). >> >> Why not? > > It is possible to hit situation when ODR will be violated, e.g. if somebody > define optional member in structure with "#if defined(NDEBUG)" condition. > Something like this: > http://stackoverflow.com/questions/20833226/library-headers-and-define > >> >> /M >> >> -- >> Magnus Therning OpenPGP: 0x927912051716CE39 >> email: mag...@therning.org jabber: mag...@therning.org >> twitter: magthe http://therning.org/magnus >> >> We act as though comfort and luxury were the chief requirements of >> life, when all that we need to make us happy is something to be >> enthusiastic about. >> -- Albert Einstein > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
