On Mon, 2015-07-13 at 06:29 -0500, Norbert Thiebaud wrote:
> On Mon, Jul 13, 2015 at 1:22 AM, David Ostrovsky <d.ostrov...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
