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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
