Thank you!

At MSYS2 we are using older revision of this patch: https://github.com/msys2/MINGW-packages/commit/e071f276d31a8d214c2f30530eb9ac3ed44fffc7#diff-7f8e056c3dca04423132b5e4e1d36813

Little background:
Recent CMake versions changed behaviour on MinGW and treat .a as static libs only. Currently CMake creates omp.a as the import library and new CMake doesn't like that.

I don't have strong opinion here as I don't know this topic well (things just worked so far).
That said if Clang stops working as a drop-in replacement for GCC with commonly used build systems, MSYS2 will have to carry one more patch to bring back old behaviour.

Thanks, sounds good.

I don't know why AddLibGCC has to be called twice but that doesn't really matter for this diff.

Wouldn't it better fit in AddLibGCC?

No worries.
Mateusz Mikuła <mati865@gmail.com>

Added test.

@mstorsjo @rnk will be away since June

With _GNU_SOURCE removed I was able to successfully build everything without this diff.
I cannot test it today but I believe this updated diff would have fixed the error.

Indeed, I'll see if I can build all LLVM related packages without _GNU_SOURCE. Otherwise I'll guard it with #ifndef _GNU_SOURCE instead.

Perhaps you are building with Clang?
I don't remember the message but GCC emits error about incompatible definition and declaration of vasprintf. I can build it without the patch and paste the error if you want.

Applied review comment and formatted.

Confirming that this patch fixes linking MinGW Rust with LLD.

MSYS2 provides LLVM built with LLVM_BUILD_LLVM_DYLIB=TRUE and hits the same issue. So far it was using this hack: https://github.com/msys2/MINGW-packages/blob/f31bc199ade4d1025cda9bb5aed4427f80d3c584/mingw-w64-clang/0012-fix-testplugin-linking.patch
Applying set(LLVM_LINK_COMPONENTS Core) from this diff also fixes the build.

Can somebody land it before LLVM 8 is branched? Patch author does not have commit access.

@jlpeyton OP doesn't have commit access.

Sorry @martell I totally forgot about it.
I'll test D33638 later today.

Some time ago I both enabled __float128 and defined macro but using it (__float128) cased segfaults. So I reduced it to HasFloat128 and haven't upstreamed it due to broken tests. It's good to see things improved.

@EricWF I think basic usage should be fine as soon as libc++abi gets linked properly. I suppose it haven't changed much since https://reviews.llvm.org/P7981
Back then replacing libc++abi with libsupc++ with few more hacks created almost-working libc++.

I don't know if it is MSYS2 specific or general MinGW issue but liblibc++.a is created. Could you check your build?
Here is line to blame: https://github.com/llvm-mirror/libcxx/blob/master/lib/CMakeLists.txt#L246

Looks fine for MinGW on Windows.

Ping

Thank you @rnk
Could you check https://reviews.llvm.org/D29772 ? Looks like there was problem with commit

Ping

Ping

@asl it is still not commited.
Something went wrong?

Thank you.

Thank you.

Ping.

Commit it please when you aren't busy.
Thanks in advance.

https://reviews.llvm.org/D29952 depends on this.

I suppose those 4 lines were your concern: https://github.com/llvm-mirror/llvm/blob/3ca564103abdd0c70f28f270873a2e535c245a6f/CMakeLists.txt#L231

If there are no further objections it can be committed by somebody.

It might be not relevant but it broke llvm-config --libs --link-shared when LLVM is built with:

-DLLVM_BUILD_LLVM_DYLIB=ON \
-DLLVM_LINK_LLVM_DYLIB=OFF \

That's valid concern, I'll try tomorrow to find out how it works.

Fixed intend

Final decision is left for @rnk and @asl but I'm still against using GCC "internal" headers in the way they aren't supposed to be used. And have MinGW Clang behaving like Linux Clang.

@yaron.keren, @rnk I would like to see OpenMP support by MinGW Clang but using GCC "internal" headers is just wrong.

My GPU has died in the meantime but openmp project doesn't seem buildable with mingw-w64 based compilers.
So the case is still open.

omp.h on Linux is supported by OpenMP package https://www.archlinux.org/packages/extra/x86_64/openmp/files/
I haven't tried to build it on win32 yet but since my examination session at college is over I'll try it in following days.

@yaron.keren those includes are not available in native Linux Clang:

float128_ex.cc:2:10: fatal error: 'quadmath.h' file not found
#include <quadmath.h>
         ^

And at least 2 of GCC includes clash with Clang includes:

Removed adding GCC includes for all mingw hosts.

I know why mingw-w64 limits.h weren't used (check first comment).
At first I was using this hack:

diff -urN clang.orig/3.9.0/include/limits.h clang/3.9.0/include/limits.h
--- clang.orig/3.9.0/include/limits.h	2016-09-26 22:29:13.496441000 +0200
+++ clang/3.9.0/include/limits.h	2016-09-26 22:29:34.189625100 +0200
@@ -28,7 +28,7 @@
 /* The system's limits.h may, in turn, try to #include_next GCC's limits.h.
    Avert this #include_next madness. */
 #if defined __GNUC__ && !defined _GCC_LIMITS_H_
-#define _GCC_LIMITS_H_
+#define _LIMITS_H___
 #endif

// c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
// c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed

for Clang is wrong on Windows because including limits.h will not show an error and won't really include mingw-w64 limits.h
Output of code from my earlier comment without patch:

error: use of undeclared identifier 'PATH_MAX'
int main() { char buf[PATH_MAX]; }

I haven't used cross compiled Clang on Linux so I added #ifndef LLVM_ON_WIN32 guard for this code.
With this guard Clang on Windows uses include paths like native Clang on Linux

I don't know about Linux but on Windows this code was causing issue: