Building QEMU with the LLVM MinGW Toolchain

[falhumai96]

Hello @mstorsjo,

Did you try, or have you had any success, building QEMU with the LLVM MinGW toolchain?

I have built all the required dependencies (hence the long discussion about building Gettext in LLVM MinGW in earlier issue 😀), but now I am at a point where the compiler initially complains about the non-existence of standard C headers (such as stdint.h). Then, I manually set the CPATH environment variable to point to the generic-w64-mingw32/include directory, and now the Clang compiler frontend seg faults and fails the QEMU build. The part that fails is at the step where it builds the emulated Linux BIOS.

[mstorsjo]

Did you try, or have you had any success, building QEMU with the LLVM MinGW toolchain?

I haven't tried

I have built all the required dependencies (hence the long discussion about building Gettext in LLVM MinGW in earlier issue 😀), but now I am at a point where the compiler initially complains about the non-existence of standard C headers (such as stdint.h). Then, I manually set the CPATH environment variable to point to the generic-w64-mingw32/include directory,

Instead of just overriding it, you definitely should look into why it isn't finding them. Can you quote a compiler invocation where it fails?

Also for context - if I remember correctly, you've earlier been building in MSYS2, but if you have the generic-w64-mingw32 directory, you're cross compiling. Is that true?

and now the Clang compiler frontend seg faults and fails the QEMU build. The part that fails is at the step where it builds the emulated Linux BIOS.

If it's a proper compiler crash, you'd need a debug build of clang to figure it out. If it's reproducible without including all of your files (e.g. from a compilation command that contains -c, remove that and replace it by -E to only do preprocessing and change the -o option to output to a separate .c file. And then redo the original compile command on that .c file instead. If the crash still is present, it's possible for someone else to debug it, if provided with the preprocessed .c and the full command.

But in this case I would first focus on what's done differently that causes it to not find the right headers. I believe this is the real root cause and the crash will vanish once the real root cause is fixed.

[falhumai96]

Also for context - if I remember correctly, you've earlier been building in MSYS2, but if you have the generic-w64-mingw32 directory, you're cross compiling. Is that true?

Yes, I am cross-compiling from Linux, because it is much faster from the Linux filesystem, and MSYS2 is deadly slow, even on the configure of some projects.

But in this case I would first focus on what's done differently that causes it to not find the right headers. I believe this is the real root cause and the crash will vanish once the real root cause is fixed.

I believe QEMU uses -nostdlib flag in some places, and hence why it couldn't find the standard libraries. I will send the CPATH, LIBRARY_PATH, and PATH environment variables' values relevant to the problem, as well as the configure and the make command I executed that generated the problem shortly.

[mstorsjo]

Yes, I am cross-compiling from Linux, because it is much faster from the Linux filesystem, and MSYS2 is deadly slow, even on the configure of some projects.

+1, yes it's much nicer to cross compile, at least as a first step while things still don't work at all.

But in this case I would first focus on what's done differently that causes it to not find the right headers. I believe this is the real root cause and the crash will vanish once the real root cause is fixed.

I believe QEMU uses -nostdlib flag in some places, and hence why it couldn't find the standard libraries.

The -nostdlib flag doesn't affect where it finds include files.

I will send the CPATH, LIBRARY_PATH, and PATH environment variables' values relevant to the problem, as well as the configure and the make command I executed that generated the problem shortly.

These aren't quite so interesting (as I don't have time to try to reproduce the full build myself); the interesting thing is the actual compiler invocation command where the makefile runs the compiler, when it fails to find the headers.

The part that fails is at the step where it builds the emulated Linux BIOS.

Actually, if building a linux BIOS, I believe it shouldn't use the mingw headers at all.

The primary point here would be to try doing the same build with GCC, and if that works, figure out what differs at this particular point.

[falhumai96]

@mstorsjo Ok, so I got, somehow, to the root of this segmentation problem. The problem is that -m16 flag, which is required to build roms/openbios/arch/x86 of the QEMU project, for example, in the LLVM MinGW toolchain seems to be broken and throws a segmentation fault. I tried to compile a simple C source file with the same flag, and I got the same segmentation fault.

[mstorsjo]

@mstorsjo Ok, so I got, somehow, to the root of this segmentation problem. The problem is that -m16 flag, which is required to build roms/openbios/arch/x86 of the QEMU project, for example, in the LLVM MinGW toolchain seems to be broken and throws a segmentation fault. I tried to compile a simple C source file with the same flag, and I got the same segmentation fault.

FWIW, the clang included here is a totally unmodified vanilla clang.

But even if you build the qemu binaries for windows with llvm-mingw, there's no need to use that compiler for building a linux bios image - I'd presume that would be done with a native linux compiler. (The clang binary in llvm-mingw should work fine for that as well, but there's no need to use this instead of the system default gcc, even if you use llvm-mingw for the cross built windows parts.) However, as I'm not familiar with qemu's build system (e.g. how is this done if building on windows - is that part skipped altogether there, if one doesn't have a windows->linux cross compiler available?) I don't know how this really is supposed to work.