I'm also on it after the RTF patch pushed sunday (<a href="http://cgit.freedesktop.org/libreoffice/core/commit/?id=f32fe9f5012e3ee184e1a1fca6814bee9105d8fb">http://cgit.freedesktop.org/libreoffice/core/commit/?id=f32fe9f5012e3ee184e1a1fca6814bee9105d8fb</a>), the patch for WW8ResourceModel.hxx will be avaible this evening. Thanks <div class="gmail_quote">Le 13 mars 2012 15:11, Stephan Bergmann <<a href="mailto:sbergman@redhat.com">sbergman@redhat.com</a>> a écrit : <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On 03/13/2012 03:00 PM, Lubos Lunak wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tuesday 13 of March 2012, Stephan Bergmann wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 03/13/2012 11:43 AM, Tor Lillqvist wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hmm, now that the reason for using -Wno-non-virtual-dtor has been documented (760e0d2d7329ca6fc00a8439715bae38becb168a ), I wonder, should we globally then also turn off the corresponding MSVC warning? That would be kinda predictable (from a "the usual waste of time" point of view), as I and others have committed over times dozens of WaE fixes for this very issue... (I.e. added a virtual no-op destructor in most cases). Or does gcc and MSVC warn for different cases of lack of virtual destructor? Is it certain that in all cases this warning is bogus, in both the gcc and MSVC cases? </blockquote> I think the warning is generally non-bogus. The problem is that we were not able to change the cppumaker-generated C++ headers without breaking backwards compatiblity[1], and GCC was somewhat over-ambitious with this warning[2], so had to disable it -- even if we would have preferred to keep it on. </blockquote> The original message about the problem, <a href="http://markmail.org/message/664jsoqe6n6smy3b" target="_blank">http://markmail.org/message/664jsoqe6n6smy3b</a> , mentions that it is not possible to selectively disable the warning for just the classes where we need to keep the binary compatibility. Assuming that my attached testcase correctly matches the problem, I do not see a warning with either gcc-4.6.3 or clang-3.1r152540. So it looks like we can either just enable the warning and selectively disable it, or we can have a configure check if some older gcc version has the problem (well, given that #pragma diagnostic is recent with gcc, it'll need an #ifdef anyway). $ g++ -Wall dtor.cpp -Wnon-virtual-dtor -c </blockquote> </div></div> I'm going to add protected, non-virtual dtors to the problematic classes. That's backward compatible (not 100%, in that it prevents deletes of objects through pointers to those non-virtual-dtor classes, but those are actually bugs, anyway) and clean, and no longer causes -Wnon-virtual-dtor warnings with recent GCCs. With that in place, we can re-enable -Wnon-virtual-dtor in solenv/gbuild/platform/<a href="http://unxgcc.mk" target="_blank">unxgcc.mk</a>. (I planned on bluntly always enabling it there, which might cause problems for --enable-werror on platforms with old GCC versions. Basing enabling on a GCC version check or some configure check might indeed be better.)<div class="HOEnZb"> <div class="h5"> Stephan _______________________________________________ LibreOffice mailing list <a href="mailto:LibreOffice@lists.freedesktop.org" target="_blank">LibreOffice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </div></div></blockquote></div> -- Arnaud Versini