[Libreoffice] [REVIEW-3-4-5]Re: gcc 4.6.2 + boost 1.48.0 and unordered_map assignment operator const issues [was gcc 4.6.2]

[Rafael Cabral]

Great!

My initial proposed fix is partially right when it to comes to 
"reimplement the operador="  (not sure about the casts) whenever the 
compiler is in the C++03 or bellow mode or if C++0x is not supported as 
well according :

http://www.boost.org/doc/libs/1_48_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator.

Thanks all of you.
Rafael Cabral


On 12/21/2011 10:15 AM, Petr Mladek wrote:
> Caolán McNamara píše v St 21. 12. 2011 v 11:38 +0000:
>
>> 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.
> The patch makes sense and looks safe to me. We use the same setting in
> libreoffice-3-5 branch...
>
> So, I have pushed it to the libreoffice-3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=9c2ab9f4febec2b2c5fac25469f1d0cfedc6af5e
>
> We need two more approvals for 3-4-5 branch.
>
> Thanks a lot for looking into it.
>
>
> Best Regards,
> Petr
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice