compiler-rt: add make solution to bootstrap for mingw-w64

[martell]

Summary

I know we will be moving forward with the cmake fixes but I wanted to submit something useful for users in the mean time.
From what I can gather this doesn't use autotool and just invokes make directly so it might be something to have until cmake is ready to bootstrap.

The cmake work around I am currently using is not suitable for upstreaming but this should be
but for some reason I can't currently get it to compile chkstk or the recently added chkstk2?

I intend to update this to support 3 targets x86_64 i686 and armv7 (aka thumb2 win NT)

[martell]

Updated to support arm and i386
If the end user has i686 they will just have to rename when they are copying as i386 is the default in the makefiles.
Same applied for arm to armv7 under winNT
Also remove -Werror until the armv7 ifdef's out pcs for _WIN32

having make find chkstk still remains the issue.

[martell]

updated i686 to use -m32

[samsonov]

Hm, I understand why this patch can be useful, but not entirely sure we want to upstream it and therefore let other people use it, given the effort to switch to CMake entirely ASAP - it means more people will have to change their workflows. Chris, WDYT?

[martell]

In D14290#280264, @samsonov wrote:

Hm, I understand why this patch can be useful, but not entirely sure we want to upstream it and therefore let other people use it, given the effort to switch to CMake entirely ASAP - it means more people will have to change their workflows. Chris, WDYT?

On this my reason for the upstream is because it is an immediate solution.
I only intend to add support for builtins to this and nothing more.
It looks like it might be some time for the bootstrapping via cmake is ready.
At that point I assume we would dump this along with the rest of the other make targets.

We currently have OSX IOS and Linux buildable in this mannor so I don't see the harm in adding mingw until cmake is ready

[compnerd]

make/platform/clang_mingw.mk

7

What happens when llvm-ar is not found? I don't think using llvm-ar since we can't bootstrap that. It should use ar.

24

The -rtlib flags here are irrelevant. The builtins are static libraries, no link will be performed. -m32 on ARM is incorrect. There is no 32-bit or 64-bit there. 64-bit ARM is armv8, not armv7.

34

This isn't Linux :-).

37

This shouldn't be needed since no shared libraries will be created.

[samsonov]

Not that I see harm in it, we just don't plan to support it. We still have Makefile on Mac for historic/legacy reasons, as there are known clients/systems that used to depend on this build process. Anyway, I have no strong opinion here, and will happily delegate Windows-related stuff to Saleem :)

[martell]

Address Saleem's comments :)

[compnerd]

At the very least, please remove the -m32 and -m64. This is fine for the time being, but I believe that at some point this is going to go away with the rest of the make based build system, so you may have to move to cmake in the near future.

make/platform/clang_mingw.mk

6

This really is better as cc.

23

Actually, why do you need the ABI specification? The target architecture already does the right thing. That is -m64 and -m32 are superfluous.

make/platform/clang_mingw.mk

+Description := Static runtime libraries for mingw-w64
+
+###
+
+CC := clang
+AR := llvm-ar
+
+Arch :=
+Configs :=
+
+SupportedArches := x86_64
+
+Configs += builtins-x86_64
+Arch.builtins-x86_64 := x86_64
+
+###
+
+CFLAGS := -Wall -Werror -O3 -fomit-frame-pointer
+CFLAGS.builtins-x86_64 := -target x86_64-windows-gnu $(CFLAGS) -rtlib=compiler-rt -m64
+
+FUNCTIONS.builtins-x86_64 := $(CommonFunctions) $(ArchFunctions.x86_64) chkstk
+
+# Always use optimized variants.
+OPTIMIZED := 1
+
+# We don't need to use visibility hidden on Linux.
+VISIBILITY_HIDDEN := 0
+
+SHARED_LIBRARY_SUFFIX := a