On Wed, 5 Sep 2018, Frédéric wrote:
However, lld isn't fully compatible with all details of the GNU linker for
the mingw target - in particular, lld can't handle import libraries
produced by binutils. So it's not right now usable as a drop-in
replacement in an existing mingw setup, you need a separate mingw
environment built from scratch with llvm-dlltool.
So that means using also clang++ as C++ compiler?
Yes, this setup uses clang for all compilation, no GCC involved. The setup
does provide <triplet>-gcc/g++ aliases though that invoke clang.
I'm maintaining a setup for building just such an environment, have a look
at https://github.com/mstorsjo/llvm-mingw.
Thanks, I will have a look at it.
I have also seen this projet that also builds a llvm toolchain for
cross-compilation:
https://github.com/tpoechtrager/wclang
This is only for using clang as compiler, but still using the normal
binutils tools for the rest.
Clang should work fine for a drop-in replacement like that; you can swap
GCC for clang for individual object files and everything should be
fine. It's lld that you can't swap in into a normal binutils based
environment though.
I'm only using
compiler_rt/libunwind/libcxxabi/libcxx instead of libgcc/libstdc++ though,
you mean that you use the standard library of llvm instead of that one of gcc?
What about pthread, i.e. C++11 threads?
libcxx supports C++11 threads on windows without using any winpthreads
library inbetween. My toolchain setup still builds winpthreads as a
library for anybody who wants to build code which only uses pthreads as
threading API though.
// Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
