On Mon, 2015-07-13 at 06:29 -0500, Norbert Thiebaud wrote:
On Mon, Jul 13, 2015 at 1:22 AM, David Ostrovsky <d.ostrovsky@gmx.de> wrote:
There weren't any changes in the affected file textdoc.cxx between those
two patch sets.
that is a bold thing to say when a patch change stuff like uno headers
or rtl headers
I see how uno and rtl headers changes look suspicious, but the removal
of get_pointer() function there is completely unrelated.
tb66 is Yosemite
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
tb60 is Maverick
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
This is a known compiler bug; now with access to Mavericks:
$ clang++ --version
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
and with this reproducer: [1] it's failing in the same way as on TB 60:
__functional_03:43:11: note: candidate function not viable: 'this'
argument has type 'const std::__1::__mem_fn<int foo::*>', but method is
not marked const
operator() (_A0& __a0)
To rectify it:
1. Upgrade Mavericks to Yosemite
2. Upgrade Xcode to Xcode 6.3.2 (Build version 6D2105)
$ clang++ --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
And now it works:
$ clang++ -Wno-c++11-extensions mem_fn_const_problem.cxx && ./a.out
42
Before new Xcode activation this diff shows the culprit:
$
diff
/Applications/.prepare-Xcode.app/reloc/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional
1224c1224
< operator() (_ArgTypes&&... __args) const
---
operator() (_ArgTypes&&... __args)
And your patch 8 would have failed the same way on tb58/tb59/tb60
It requires a lot of efforts and time to upgrade all TBs to the newest
baseline: 18 min. for OS + 22 min. for XCode. And we don't have time to
do that. I understand all that.
But what is the value of having conflicting tool chain versions
verifying the Gerrit changes? So that change owners couldn't really
trust the verification results, or if they do and submit changes that
were approved by TB with up-to-date tool chain, they jeopardize green
master or even stable release branch, because the same change is
identified as breakage by a TB with stale tool chain?
My suggestion is either to downgrade TB66 or upgrade all other Mac OS X
TBs to the same baseline.
[1] http://paste.openstack.org/show/371884
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.