cmake: Support building inside MinGW/MSYS environment on Windows

[lescopc]

Describe the bug
During 'cmake' step, Zephyr fails to auto-detect the 'gnuarmemb' toolchain because the toolchain fails to compile a dummy C file

To Reproduce
cmake -DBOARD=qemu_cortex_m3 -DZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb -DGNUARMEMB_TOOLCHAIN_PATH=/c/Users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi %ZEPHYR_BASE%/samples/hello_world

Expected behavior
[...]
-- Found toolchain: gnuarmemb (/c/Users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi)
[...]
-- The C compiler identification is GNU 10.3.1
-- The CXX compiler identification is GNU 10.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /c/Users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc.exe
[...]

Impact
showstopper

Logs and console output
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /c/Users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc.exe
Build flags:
Id flags:

The output was:
1
c:/users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: c:/users/%USER%/gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1\libc.a(lib_a-exit.o): in function exit': /data/jenkins/workspace/GNU-toolchain/arm-10/src/newlib-cygwin/newlib/libc/stdlib/exit.c:64: undefined reference to _exit'
collect2.exe: error: ld returned 1 exit status

Environment

• OS: Windows: MinGW-w64
• Toolchain: gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-eabi
• Commit SHA: ba939b1
• which cmake
  /mingw64/bin/cmake
• which python3
  /mingw64/bin/python3

How to Fix
diff --git a/cmake/toolchain/gnuarmemb/generic.cmake b/cmake/toolchain/gnuarmemb/generic.cmake
index 1ea30ab70d..f44aeffaae 100644
--- a/cmake/toolchain/gnuarmemb/generic.cmake
+++ b/cmake/toolchain/gnuarmemb/generic.cmake
@@ -24,6 +24,7 @@ set(BINTOOLS gnu)

set(CROSS_COMPILE_TARGET arm-none-eabi)
set(SYSROOT_TARGET arm-none-eabi)
+set(CMAKE_EXE_LINKER_FLAGS_INIT "--specs=nosys.specs")

set(CROSS_COMPILE ${TOOLCHAIN_HOME}/bin/${CROSS_COMPILE_TARGET}-)
set(SYSROOT_DIR ${TOOLCHAIN_HOME}/${SYSROOT_TARGET})

[stephanosio]

This happens when you have a dirty cache.

Try deleting the toolchain cache directory (one that contains ToolchainCapabilityDatabase, usually ~/.cache/zephyr) and re-building.

Also, Zephyr SDK is now available on Windows -- please use the Zephyr SDK whenever possible.

[lescopc]

I removed both generated files and cache ones before submitting this bug.
Deleting the cache does not fix my issue but my patch does. They do the same in LLVM (cf: cmake/toolchain/llvm/generic.cmake)

Also, I'd prefer use MinGW-w64 than Native Windows SDK (as I'm a Unix user). Also, I've one patch to submit to make the whole Zephyr compile & run on QEMU.

[stephanosio]

Using MSYS2/mingw64, the build environment is completely broken (this is not supported anyway):

CMake Error in CMakeLists.txt:
  Target "zephyr_interface" contains relative path in its
  INTERFACE_INCLUDE_DIRECTORIES:

    "c:/msys64/home/stephanos/gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.2.1/include"

Using the MinGW environment included in "Git for Windows" (i.e. git-bash), compilation proceeds without any problem; though, in this case, I am using the Windows native CMake and Ninja installed through Chocolatey, as described in the Getting Started Guide.

This problem is not reproducible with the above configuration. It might be failing on your system because you are using the MinGW CMake and Ninja and that is somehow breaking build system, but that is not a supported configuration anyway.

If you are forced to use Windows, go with either Windows native tools (you can still use bash shell with git-bash) or WSL.

MINGW64 ~
$ which cmake
/c/Program Files/CMake/bin/cmake

MINGW64 ~
$ which ninja
/c/ProgramData/chocolatey/bin/ninja

MINGW64 ~
$ which make
/c/ProgramData/chocolatey/bin/make

[lescopc]

I fixed that first error with a 'pull request' I'll push in few minutes.
There are only a second PATH problem. So, Zephyr build is not completely broken on MinGW :) .
Yes, I do use git-bash (which is based on MinGW-w64 + Unix Makefile (not Ninja)) because it is way faster than MSYS2 and does not need to install/use a WSL environment. Also, it is built to run GCC.

Well, using native Windows tools under MinGW is not my choice because I try not to "mix" environment as much as possible.

Finally, it is up-to-you. I agree that MinGW is not supported at all, but today it is "only" 2 minor patches that does not impact other builds (from what I've tested/seen) -> minor effort for supporting another Host -> great :)

[stephanosio]

today it is "only" 2 minor patches that does not impact other builds

Have you tried building various tests using the twister (e.g. at least tests/kernel)? I highly doubt the fix is going to be just two minor patches.

Also west seems to be broken under certain flavours of MSYS2 environment too:

MINGW64 ~
$ west
Traceback (most recent call last):
  File "/usr/bin/west", line 8, in <module>
    sys.exit(main())
  File "/usr/lib/python3.9/site-packages/west/app/main.py", line 786, in main
    app.run(argv or sys.argv[1:])
  File "/usr/lib/python3.9/site-packages/west/app/main.py", line 94, in run
    self.config = west.configuration.Configuration(topdir=self.topdir)
  File "/usr/lib/python3.9/site-packages/west/configuration.py", line 152, in __init__
    self._system_path = Path(_location(ConfigFile.SYSTEM))
  File "/usr/lib/python3.9/site-packages/west/configuration.py", line 586, in _location
    raise ValueError('unsupported platform ' + plat)
ValueError: unsupported platform MINGW64_NT-10.0-19044

If the fix is relatively simple, I am not opposed to adding the MinGW/MSYS support but it likely is not going to be.

[stephanosio]

Marking this as an enhancement, since this is not really a bug as described above.

[stephanosio]

Just out of curiosity and also to document the MinGW/MSYS2 developer experience for future reference, I did a brief investigation and found a series of problems:

1. west does not work under certain flavours of MSYS2.

   ValueError: unsupported platform MINGW64_NT-10.0-19044
   

2. unable to install some required Python packages (pip3 install -r scripts/requirements.txt)

   Collecting psutil
     Using cached psutil-5.9.0.tar.gz (478 kB)
     Preparing metadata (setup.py) ... error
     error: subprocess-exited-with-error
   
     × python setup.py egg_info did not run successfully.
     │ exit code: 1
     ╰─> [1 lines of output]
         platform cygwin is not supported
         [end of output]
   

3. twister cannot run tests in QEMU because psutil Python package cannot be installed:

   Install psutil python module with pip to run in Qemu.
   

4. all userspace-enabled tests and samples fail to build because the syscall generation script (gen_syscalls.py) errors out:

     File "/home/stephanos/zephyrproject/zephyr/scripts/gen_syscalls.py", line 173, in typename_split
       raise SyscallParseException("Malformed system call invocation")
   __main__.SyscallParseException: Malformed system call invocation
   

5. TF-M components fail to build because of missing Python cryptography package (wheel is not available for one of the dependencies and it fails to build under MinGW).

In summary, unless you like making your life hard for no good reason, don't do this.

p.s. note that these are just some of the problems I found; there are likely tons more.

[stephanosio]

Also note that MSYS2 support has been explicitly removed in #11300.

[lescopc]

I did a brief investigation

Thank you for giving it a try!

Also note that MSYS2 support has been explicitly removed in #11300.

Sorry, I didn't find it on my search

I never used twister and when I tried to used west (on v1.14) it was really broken. I had to completely uninstall it otherwise it would break my Zephyr build. I've never tried to re-install it since.
I didn't face the python script problem because I don't use the requirements script. As an end-user, I simply need pyelftools, pyyaml and a third one (I can't recall its name) to generate the syscalls hash table.
My life is simply:
once

python3 -m pip install pyelftools pyyaml
git clone zephyr myzephyr

then

cd myzephyr && export ZEPHYR_BASE=`pwd`
mkdir build && cd build
cmake -Dxxxx
make

That's really easy! Hope I can keep it that way :)
Well, I'll check the 5 points you mentionned when possible. I'm interested in your "developer side/view"

[zephyrbot]

Hi @tejlmand,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@lescopc you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!