llvm dev - Nov 2016 - Llvm build is broken (at least on FreeBSD)

Current revision 285840 fails to build on FreeBSD.

I used the command:
cmake -G "Unix Makefiles" ../llvm -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_PREFIX:PATH=/opt/llvm/current && gmake

(I am aware of FreeBSD llvm/clang ports, but the source build should 
always succeed as well.)

Yuri


---errors---
Scanning dependencies of target gtest
[ 91%] Building CXX object 
utils/unittest/CMakeFiles/gtest.dir/googletest/src/gtest-all.cc.o
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-all.cc:42:
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest.cc:132:
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-internal-inl.h:153:3:
error: field of type 'testing::internal::String' has private default 
constructor
   GTestFlagSaver() {
   ^
/usr/local/include/gtest/internal/gtest-string.h:157:3: note: declared 
private here
   String();  // Not meant to be instantiated.
   ^
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-all.cc:42:
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest.cc:132:
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-internal-inl.h:153:3:
error: field of type 'testing::internal::String' has private default 
constructor
   GTestFlagSaver() {
   ^
/usr/local/include/gtest/internal/gtest-string.h:157:3: note: declared 
private here
   String();  // Not meant to be instantiated.
   ^
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-all.cc:42:
In file included from 
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest.cc:132:
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-internal-inl.h:153:3:
error: field of type 'testing::internal::String' has private default 
constructor
   GTestFlagSaver() {
   ^


https://llvm.org/bugs/show_bug.cgi?id=30877

On 2 November 2016 at 12:04, Yuri via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Current revision 285840 fails to build on FreeBSD.
It could be a recent commit, but our buildbots are down, so we'll have to
wait.

The best thing to do right now is to "git blame" on the file that
fails and, if it's a commit from today, email to the developer asking
to look into / revert the patch, at least until all the bots are up
and running.

cheers,
--renato

fwiw we aren't seeing a build issue, but "we" do things very
differently.

This is based off fully open source clang packages with no gnu at all.

Binaries
---------------
http://c591116.r14.cf2.rackcdn.com/FreeBSD/nightly/clang-suite-nightly-installer.run

Source and patches
--------------------------
We're building things a little different. This was inspired by our
internal build which tightly builds and couples all components
together without gcc deps. (Not saying this is the "right way", but
it's how we're doing it)

# Source is here
https://github.com/pathscale/clang-suite/

# The handful of small patches we're apply are here
# We will slowly work to get them upstream
https://github.com/pathscale/clang-suite/tree/master/patches

On Thu, Nov 3, 2016 at 3:22 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 2 November 2016 at 12:04, Yuri via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> Current revision 285840 fails to build on FreeBSD.
>
> It could be a recent commit, but our buildbots are down, so we'll have
to wait.
>
> The best thing to do right now is to "git blame" on the file that
> fails and, if it's a commit from today, email to the developer asking
> to look into / revert the patch, at least until all the bots are up
> and running.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Nov 2, 2016, at 12:04 PM, Yuri via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Current revision 285840 fails to build on FreeBSD.
> 
> I used the command:
> cmake -G "Unix Makefiles" ../llvm -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX:PATH=/opt/llvm/current && gmake
> 
> (I am aware of FreeBSD llvm/clang ports, but the source build should always
succeed as well.)
> 
> Yuri
> 
> 
> ---errors---
> Scanning dependencies of target gtest
> [ 91%] Building CXX object
utils/unittest/CMakeFiles/gtest.dir/googletest/src/gtest-all.cc.o
> In file included from
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-all.cc:42:
> In file included from
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest.cc:132:
>
/xpool/llvm/latest/llvm/utils/unittest/googletest/src/gtest-internal-inl.h:153:3:
error: field of type 'testing::internal::String' has private default
constructor
>  GTestFlagSaver() {
>  ^
> /usr/local/include/gtest/internal/gtest-string.h:157:3: note: declared
private here
Looks like it picked up some header from your machine instead of using the gtest
bundled with llvm
(llvm/unittest/googletest/include/gtest/internal/gtest-string.h). Not sure
how/why that can happen.

- Matthias

On 11/02/2016 12:39, Matthias Braun wrote:
> Looks like it picked up some header from your machine instead of using the
gtest bundled with llvm
(llvm/unittest/googletest/include/gtest/internal/gtest-string.h). Not sure
how/why that can happen.

This must be the bug in cmake files, because it should prepend the paths 
of all bundled packages.


Yuri