Differential D23654
[CMake] Rename back SIMPLE_SOURCE to compile as C++ Authored by Hahnfeld on Aug 18 2016, 5:22 AM.
Details This was changed in rL276151 and causes problems if the C++ compiler does not support the same arches as the C compiler. Additionally, -fno-exceptions is passed in (if available) to work around the case where no libunwind is available.
Diff Detail
Event TimelineComment Actions Sorry, forgot to respond to @beanz' question of how does it fail. When building for ARM: error: undefined reference to '__aeabi_unwind_cpp_pr0' This is provided by libunwind. There are a few different providers for the personality routine, but that requires that you build those, which depend on the builtins, so we can't really guarantee that it exists (bootstrapping). From your description, it sounds like you want to ensure that the C++ compiler is valid? Why not add a secondary test that does a *compile only* test for C++ support without depending on C++ headers? Something like a class definition should be sufficient for that. Alternatively, we could try -fno-exceptions -fno-unwind-tables as part of the compile options for the test target. Comment Actions If you only need the builtins, you can directly configure lib/builtins. There is also support for that when checking out compiler-rt into runtimes/ in the LLVM root directory.
Yes, a valid C++ compiler is definitely needed for the sanitizers. And the renamed test only relies on C header files, so I don't really see how you would be able to compile the sanitizers if this simple test isn't doable for your compiler.
If the sanitizers are fine with that, it's worth trying... Comment Actions @compnerd, I see the libunwind problem as different but more complicated (so no quick solution). I don't want to block any progress there, so please proceed as you see fit. When you get a chance you and I should discuss unwind in more detail. I have some ideas on how to solve that problem. WRT this patch, I have no objection as it is, but I'll leave that between @Hahnfeld and @compnerd to work out an acceptable solution. -Chris Comment Actions The sanitizers definitely need the unwind tables on ARM. They are needed for the stack trace. I don't know off the top of my head if the sanitizers use exceptions. But, for the C++ compiler test, I think thats reasonable. If you are doing static runtime builds, the library need not be present at runtime compile time. Comment Actions That sounds like a weird setup and in the current state a much more common scenario is broken: Most of the systems will have the same libraries at runtime as they have at configure and compile time. I insist on my main point: We must test the C++ compiler on configure time if we use it at build time and that's really the case here. Do you have a suggestion of a C++ test that would also work in your setup? Comment Actions As Chris had no objection, I would like to commit this one unless you can present a fix that also works for me. Feel free to (sometimes) find me on IRC Comment Actions I thought I had mentioned a test that could work: build a simple C++ source file without exceptions and unwind tables. This would obviously not run very well, but would let you test the compiler. Comment Actions Then please tell me what's difficult about #include <stdlib.h>
#include <stdio.h>
int main() {
printf("hello, world");
}as it is currently?!? There are no exceptions, no unwinding and not even C++ at all! Comment Actions @compnerd, if it matters, the llvm/runtimes directory can now ensure that the builtin libraries are built before the sanitizers are configured. A solution for libunwind also isn't too difficult via the runtimes directory because we can configure libunwind with compiler-rt and connect the dependencies. Comment Actions Please try the suggestion from @compnerd to build the sample source with -fno-exceptions -fno-unwind-tables before committing. This patch in its current form will break builds in cases where libunwind is unavailable. Comment Actions Ah, now I finally see that the sanitizers are built with -fno-exceptions if available, sorry about that. However, it uses -funwind-tables so I would be against disabling them. Would the other flag be enough to make it work? Comment Actions Yes, just -fno-exceptions is sufficient to prevent errors in my builds. Thanks! I'm fine with this being merged given the addition of that flag. |