[LLVMdev] Purpose of LLVM_ENABLE_LIBCXX and LLVM_ENABLE_LIBCXXABI

Schlottke-Lakemper, Michael m.schlottke-lakemper at aia.rwth-aachen.de
Tue Jul 28 08:57:51 PDT 2015


Wouldn’t it it be possible to add a flag like the one used in the OpenMP subproject? There they default to linking to the non-functional libgomp (as far as I understand it), and if people want to use the actual libomp runtime, they have to specify -fopenmp=libomp when compiling/linking a program. At the same time, it is possible to use the libomp runtime library by default by specifying

-DCLANG_DEFAULT_OPENMP_RUNTIME=libomp

at configuration time when building LLVM. That way things would not break for existing users with unsupported systems while making things for users like us *much* easier :)

Regards,

Michael

> On 28 Jul 2015, at 15:53 , Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 28 July 2015 at 14:44, Martell Malone <martellmalone at gmail.com> wrote:
>> Adding a little to the topic what criteria would we need to make a target
>> use compiler-rt and libc++ as the default in the clang driver.
>> I have successfully built a standalone clang toolchain with mingw-w64
>> without using gcc or binutils.
> 
> There was another discussion with David Chisnall, where he gave a good
> overall on some of the complications for doing so:
> 
> http://comments.gmane.org/gmane.comp.compilers.clang.devel/44037
> 
> From my point of view, we can only do something that radical when we
> can test on most environments and make sure that any combination will
> work. I don't know how to do that, though, but I expect that there
> should be enough tests in Clang to that effect.
> 
> For now, I just want to make sure it works on ARM/AArch64, even if I
> have to hack my way through it. If I can have at least a buildbot
> testing them, we'll be sure not to regress in functionality. System
> integration is a secondary issue.
> 
> cheers,
> --renato





More information about the llvm-dev mailing list