Re: [Libreoffice] gcc 4.6.2 + boost 1.48.0 and unordered_map assignment operator const issues [was gcc 4.6.2]

On Tue, 2011-12-20 at 09:30 +0000, Caolán McNamara wrote:
> On Tue, 2011-12-20 at 10:13 +0100, Petr Mladek wrote:
> > Hi Rafael,
> >
> > fixes for 3.4.5-rc2 need triple review, so I forward this mail to the
> > mailing list.
>
> We've seen this problem recently with our rawhide gcc as well and 3.4.X,
> though 3.5.X doesn't seem to have the problem

after some digging the difference between 3.4 and 3.5 that makes 3.5
build is that the gbuild modules are additionally built with -std=c++0x
on 3.5 (only the dmake ones are built with that on 3.4).

Seems that a recent boost + recent gcc causes this problem when an
boost::unordered_map is used as a baseclass for something, but asking
gcc to use -std=c++0x mode makes gcc do the right thing.

Whether its a bug in gcc or boost I'm unsure really. But it wouldn't
happen with an older boost like the builtin one, and I think using the
attached patch would allow people to build 3.4 with bleeding edge
external boost and gcc without hacking loads of copy-constructors
manually.

C.

diff --git a/solenv.orig/gbuild/platform/unxgcc.mk b/solenv/gbuild/platform/unxgcc.mk
index 2bce148..391dd5d 100755
--- a/solenv/gbuild/platform/unxgcc.mk
+++ b/solenv/gbuild/platform/unxgcc.mk
@@ -111,6 +111,12 @@ gb_CFLAGS += -fno-strict-aliasing
 gb_CXXFLAGS += -fno-strict-aliasing
 endif
 
+ifeq ($(HAVE_CXX0X),TRUE)
+#Currently, as well as for its own merits, c++11/c++0x mode allows use to use
+#a template for SAL_N_ELEMENTS to detect at compiler time its misuse
+gb_CXXFLAGS += -std=c++0x -Wno-deprecated-declarations
+endif
+
 ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
 gb_CFLAGS_WERROR := -Werror
 gb_CXXFLAGS_WERROR := -Werror