Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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.