On Thu, 2011-09-15 at 14:34 +0200, Michael Stahl wrote: > of course what also needs to be prevented is linking against system > libraries that expose STL in their interface; a quick search found me > cppunit and graphite; the mozilla/nss stuff doesn't seem to expose STL.
This is basically the scenario that caused the trouble. Its not incompatibility between debugging stl in one of our modules vs another one but incompatibility between, in practice, non-debugging system cppunit and debugging stl in our code, i.e. stuff that uses cppunit headers, runs the debugging-stl destructors on something created by non-debugging-stl. Inlines resizing/deleting stuff was one problematic one IIRC. + # cppunit and graphite expose STL in public headers Quite probably need to also handle the mysql connector as well, maybe a few more, hunspell ? Gets a bit unwieldy fast to maintain a list in configure of stuff that uses stl. For the internal cppunit and graphite probably need to pass -D_GLIBCXX_DEBUG into *their* build systems as well, no ? The edge-cases that needed to be handled seemed to pile up sufficiently high to make it hard to know if it was all handled correctly :-( C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
