Hi All,
I am first time trying build CLANG+LLVM using cmake+ninja build
system. I updated all my CLANG+LLVM sources to current trunk, and I
successfully built it using classic *make* build system. But, trying
to build the same with cmake+ninja build system resulting in following
build failures for compiler-rt sources.
Am I missing something basics here?
I use latest cmake+ninja which are built from latest sources.
I’m seeing this too. CC’ing the author ubsan stuff.
Richard, I know you were OK with only supporting Clang-bootstraps, but I don’t think that’s terribly viable here. We should be able to build ubsan’s runtime with standards conforming code unless there is some fairly extreme reason not to…
I'm seeing this too. CC'ing the author ubsan stuff.
Richard, I know you were OK with only supporting Clang-bootstraps, but I
don't think that's terribly viable here.
Just out of curiosity - why isn't that viable? I'd sort of hope to
treat optional sanitizer runtimes like, say, lld or other projects
that aren't necessary to bootstrap: viable candidates for C++11 & more
or less anything we want to use.
- David
> I'm seeing this too. CC'ing the author ubsan stuff.
>
> Richard, I know you were OK with only supporting Clang-bootstraps, but I
> don't think that's terribly viable here.Just out of curiosity - why isn't that viable? I'd sort of hope to
treat optional sanitizer runtimes like, say, lld or other projects
that aren't necessary to bootstrap: viable candidates for C++11 & more
or less anything we want to use.
Mostly, because I want to keep building and installing Clang simple. When I
wrote this, if someone checked out the Clang codebase following the
instructions on the website, and built it using CMake, it would fail to
build. The default compiler on most systems is GCC still, and so it seems
unreasonable to abandon support for it...
FWIW, I'll immediately become OK with requiring a bootstrap when the build
system does it for us, so that users can check out the code, build and
install it in "one go". I'm mostly concerned with keeping the development
process simple, not with the particulars of one host compiler vs. the other.
As a final note, it turned out to be very easy to fix this. I should have
updated this thread. I think everything will work as of r165863.
I am still getting compiler errors for compiler-rt sources as below.
Do not know, if the first argument to IsNullLiteralHelper() is to be
passed as '0' instead of false, in the below lines.
I am still getting compiler errors for compiler-rt sources as below.
Do not know, if the first argument to IsNullLiteralHelper() is to be
passed as ‘0’ instead of false, in the below lines.==========================================
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/asan/tests/asan_noinst_test.cc:
In member function ‘virtual void
AddressSanitizerInterface_GetAllocatedSizeAndOwnershipTest_Test::TestBody()’:
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/asan/tests/asan_noinst_test.cc:373:3:
error: converting ‘false’ to pointer type for argument 1 of ‘char
testing::internal::IsNullLiteralHelper(testing::internal::Secret*)’
I am also building llvm with cmake+ninja, but haven’t seen these warnings because my default gcc is somewhat old.
With newer gcc (4.6.3) I do see these warnings.
Fixed in r166093.
I’ll check if the rest of compiler-rt builds with gcc 4.6.3.
–kcc