[cfe-dev] Building with mingw64 on Windows issue

[Martin Storsjö via cfe-dev]

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.

> Currently I'm just going for builing LLVM/clang with an empty projects
> folder.
>
> set
> gcc_include_path=../../x86_64-8.1.0-release-posix-seh-rt_v6-rev0/mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0\include
> cmake -G "MinGW Makefiles" ^
> -DCMAKE_BUILD_TYPE=Release ^
> -DCMAKE_SYSTEM_NAME=Windows ^

I'm not sure if CMAKE_SYSTEM_NAME is necessary, and/or if it does any harm 
to specify it when it's not needed.

> -DCMAKE_CXX_FLAGS="-I%gcc_include_path% -I%gcc_include_path%\c++ -D_WIN32_WINNT=0x0600"
> ^
> -S C:\dev\llvm -B T:\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\build
> > cmake_result.txt 2>&1
> pause
>
> Then:
> mingw32-make --directory=T:\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\build
> -f Makefile > build_result.txt 2>&1
> pause
>
> It builds a fair bit more. I wasn't sure if previous attempts did make the
> folder: T:\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\build\NATIVE.
> But at least this is what I see now.
>
> But as I'm now stuck at:
> No rule to make target 'NATIVE/bin/llvm-tblgen', needed by
> 'include/llvm/IR/Attributes.inc.tmp'.  Stop.
>
> seen on the end of the build_result.txt file. I find it hard to decide what
> I could try next. The reason is that I'm missing a bit of a "build
> rationale". With that I mean some documentation that explains in general
> terms how the building process is designed. In it I hope to learn the reason
> for the NATIVE folder, what it contains and what llvm-tblgen.exe is designed
> to do. With that understanding I'm able to make an educated guess to try to
> set a define that might solve the specific issue I'm facing now with that
> "No rule to make target "
>
> Would there be some documentation on that topic on the internet or are you
> willing to explain this to me? I'd love to learn.

If you haven't read https://llvm.org/docs/CMake.html yet, that's 
recommended. (I don't remmeber if you've mentioned that you've read it or 
not.)

The NATIVE directory indicates that cmake thinks that you are cross 
compiling. It might be linked to you specifying CMAKE_SYSTEM_NAME even 
though it's redundant.

llvm-tblgen is a tool that reads .td files and generates code (.h/.cpp) 
out of it. So normally when you compile llvm, the build system first 
compiles llvm-tblgen and a few other tools, then uses llvm-tblgen to 
generate even more source files to compile. When cross compiling, one 
first has to build a native version of llvm-tblgen in order to be able to 
run it during the build on the build machine, even if the llvm build 
itself is supposed to be for another architecture/os.

(Even further away from your actual topic; CMake is supposed to handle 
building this automatically when cross compiling, but it doesn't really 
work for me in the cases where I've cross compiled LLVM, so for those 
cases I first build the tools in a non-cross llvm build directory, and 
point the cross build to the existing tools.)

I'm successfully building llvm with mingw/gcc within msys, with a cmake 
invocation like this:

cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_PREFIX=/foo

If buidling within msys, make sure to pick the mingw-w64-x86_64-cmake 
package instead of the one for building things that target msys itself.

I haven't tested building outside of msys in a plain cmd with mingw32-make 
though, but nothing of the errors you've shown so far indicate that as a 
problem yet.

// Martin