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

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

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

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

Yuri