> * insert arbitrary debugging code that is only present in 'special' > builds: #ifdef DBG_UTIL and #if OSL_DEBUG_LEVEL > n
Unfortunately, I think those have been mixed up in the past occasionally. When I recently tried a build with --enable-dbgutil but not --enable-debug, I came across a handful of places where some variables or class member was defined inside #if OSL_DEBUG_LEVEL > n but then those variables or class members were used inside #ifdef DBG_UTIL code, or in some DBG_whatever macro which amounts to the same. > I'm fully for discarding the old DBG_* tools entirely. I probably agree. The reason why I wanted to build with --enable-dbgutil was that I was trying to track down what I suspected was heap corruption, on Windows, and using --enable-dbgutil makes the built binaries use the so-called debugging runtime that does (as far as I know) more heap correctness checking. But unfortunately that build didn't turn out usable anyway, it crashed on startup, and I didn't have time to dig into it more. But anyway, I wonder, if we drop --enable-dbgutil, should then --enable-debug (or building individual modules with debug=true) cause the debugging runtime to be used? Will it cause horrible crashes if some DLLs use the debugging runtime and some not? --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
