[cfe-dev] Building with mingw64 on Windows issue

[Martin Storsjö via cfe-dev]

On Sun, 9 Dec 2018, Maarten Verhage wrote:

> Hi Martin,
>
> Ok, good progress now. Your suggestion to remove the
> DCMAKE_SYSTEM_NAME=Windows line did it. Now I don't have that NATIVE folder
> and neither that "No rule to make target" error. Thank a lot for that. I
> could have spend hours and a lot of frustration until I finally try to
> remove that line.
>
> Now it seems to build to the end. about 4GB on the T: drive. A lib folder
> full of LLVM and clang libraries.And a bin folder full of executables.
>
> In the process there are some warnings like:
> 1)
> C:\dev\llvm\lib\IR\Core.cpp: In function 'void
> LLVMContextSetDiagnosticHandler(LLVMContextRef, LLVMDiagnosticHandler,
> void*)':
> C:\dev\llvm\lib\IR\Core.cpp:91:18: warning: cast between incompatible
> function types from 'LLVMDiagnosticHandler' {aka 'void
> (*)(LLVMOpaqueDiagnosticInfo*, void*)'} to
> 'llvm::DiagnosticHandler::DiagnosticHandlerTy' {aka 'void (*)(const
> llvm::DiagnosticInfo&, void*)'} [-Wcast-function-type]
>           Handler),
>
> 2)
> C:/dev/llvm/include/llvm/ADT/StringRef.h:302:37: warning: 'void*
> memchr(const void*, int, size_t)' specified size 18446744073709551615
> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
>
> 3)
> C:\dev\llvm\tools\clang\tools\c-index-test\c-index-test.c:1018:62: warning:
> unknown conversion type character 'l' in format [-Wformat=]
>               printf(" [Template arg %d: kind: %d, intval: %lld]",
>
> For the last one I thought I needed to set CMAKE_C_FLAGS to -std=c99 but
> when building again I do get the same warnings on that c file.

These warnings generally are harmless.

The third one stems from the fact that the common mingw setups target 
msvcrt.dll, which doesn't support formats like %lld to printf. To get 
support for that, build with -D__USE_MINGW_ANSI_STDIO=1. But I don't think 
there should be any cases like that in the core parts of llvm/clang where 
it really matters though; this file sounds like a very fringe detail.

> I realize building took some time so I set LLVM_TARGETS_TO_BUILD just to X86
> and on the mingw32-make invocation to -j4 for the 4 cores I have.
>
>> Hi Maarten,
>>
>> On Sat, 8 Dec 2018, Maarten Verhage wrote:
>>
>>> Yes, good idea. Going for x86_64-8.1.0-release-posix-seh-rt_v6-rev0! Also
>>> I
>>> did realize I made a mistake in my windows command prompt script. The
>>> reason
>>> it wasn't able to find std::mutex was that I didn't specify the include
>>> folders for the gcc includes. The header file mutex certainly is present
>>> in
>>> the mingw64 folder tree. It is also present in the win32 threads variant
>>> so
>>> I might try that too, when I see the posix variant is building LLVM/clang
>>> correctly.
>>
>> That's rather strange. Normally you don't need to manually specify the
>> include directories but they are implicit when you invoke GCC, but they
>> are implicifly found when you invoke the compiler. I'm fairly sure the
>> prebuilt GCC versions from mingw installers work that way.
>>
> You're right. I figured the specification of the include folders are
> redundant. There is another reason why in the mingw win32 threads variant
> there is an issue about utilizing the header mutex. But in the posix variant
> it just builds w/o that specification. However I'm a bit curious how cmake
> is able to find the header files within the mingw source tree.

cmake doesn't manually look for headers, but cmake calls the compiler to 
detect headers, so as long as the compiler finds them, the build system 
tests should pass just fine.

> As my goal is to have an LLVM/clang toolchain with standard Windows API
> threads what would be the next step for me?
> Or do I need to do some tests to see if my clang toolchain is stable?

You can run tests if you want to, but that requires a bit more 
infrastructure (it requires python).

> Also I'm not quite sure at which moment I need to have which toolchain bin
> folder in my PATH environment variable. My guess is to take the mingw64 bin
> folder out of my path, set the bin folder of LLVM there and build libcxxabi
> with clang and have  D_LIBCPP_BUILDING_LIBRARY and
> _LIBCPP_HAS_THREAD_API_WIN32 be set. Should the library be placed in the
> build lib folder along with the libclangxxx.a and libLLVMxxx.a files?

What you have so far is the plain compiler, which can work with any mingw 
sysroot. If you just call this clang instance, it can try to detect a 
mingw sysroot (by e.g. looking for a matching gcc in your path, and 
picking the sysroot next to it) and find the one you most probably 
intended to be used.

Or call it with "clang -target x86_64-w64-mingw32 
--sysroot=/path/to/sysroot" in order to avoid heuristics. Add "-v" to any 
clang invocation in order to get clear indications about what it does and 
what the heuristics ended up with.

This should work just fine with your existing mingw sysroot, no need to 
remove gcc from your path or so, as long as you invoke the compiler as 
"clang" and not "gcc" of course.


If you want to, you can build libcxxabi and libcxx (and libunwind, and 
compiler_rt, or try to make it work with the existing libgcc from your 
existing setup), install it on top of the existing sysroot, and call clang 
with -stdlib=libc++ to make it use that instead of libstdc++.

Now if you need llvm itself to run on top of libc++ instead of libstdc++, 
then you need to rebuild all of llvm again with this toolchain.

For the exact details on how to build and install libcxxabi/libcxx, have a 
look at the build-libcxx.sh script in my github repo - it's easier to read 
it from there than to verbally describe the process.


// Martin