CLANG64/x86_64-w64-mingw32-clang link error if C:\msys64\mingw64\bin is in PATH

[huangqinjin]

Description / Steps to reproduce the issue

set PATH=C:\msys64\clang64\bin;C:\msys64\mingw64\bin;%PATH%
C:\msys64\clang64\bin\x86_64-w64-mingw32-clang.exe -v main.c

Expected behavior

Use the the pre-built binaries from https://github.com/mstorsjo/llvm-mingw, it can run without error:

C:\llvm-mingw\bin\x86_64-w64-mingw32-clang.exe -v main.c

clang version 17.0.6 (https://github.com/llvm/llvm-project.git 6009708b4367171ccdbf4b5905cb6a803753fe18)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/llvm-mingw/bin
 "C:/llvm-mingw/bin/clang-17.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-use-init-array -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=D:/tmp -resource-dir C:/llvm-mingw/lib/clang/17 -internal-isystem C:/llvm-mingw/lib/clang/17/include -internal-isystem C:/llvm-mingw/x86_64-w64-mingw32/include -internal-isystem C:/llvm-mingw/x86_64-w64-mingw32/usr/include -internal-isystem C:/llvm-mingw/include -fdebug-compilation-dir=D:/tmp -ferror-limit 19 -fmessage-length=156 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -exception-model=seh -fcolor-diagnostics -faddrsig -o C:/Users/PEEQJH~1/AppData/Local/Temp/main-678543.o -x c main.c
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target x86_64-w64-mingw32
ignoring nonexistent directory "C:/llvm-mingw/x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/llvm-mingw/x86_64-w64-mingw32/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/llvm-mingw/lib/clang/17/include
 C:/llvm-mingw/include
End of search list.
 "C:/llvm-mingw/bin/ld.lld" -m i386pep -Bdynamic -o a.exe C:/llvm-mingw/x86_64-w64-mingw32/lib/crt2.o C:/llvm-mingw/x86_64-w64-mingw32/lib/crtbegin.o -LC:/llvm-mingw/x86_64-w64-mingw32/lib -LC:/llvm-mingw/x86_64-w64-mingw32/mingw/lib -LC:/llvm-mingw/lib -LC:/llvm-mingw/lib/clang/17/lib/windows C:/Users/PEEQJH~1/AppData/Local/Temp/main-678543.o -lmingw32 C:/llvm-mingw/lib/clang/17/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 C:/llvm-mingw/lib/clang/17/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -lkernel32 C:/llvm-mingw/x86_64-w64-mingw32/lib/crtend.o

Actual behavior

C:\msys64\clang64\bin\x86_64-w64-mingw32-clang.exe -v main.c

clang version 17.0.6
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/clang64/bin
 "C:/msys64/clang64/bin/x86_64-w64-mingw32-clang.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-use-init-array -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=D:/tmp -resource-dir C:/msys64/clang64/lib/clang/17 -internal-isystem C:/msys64/clang64/lib/clang/17/include -internal-isystem C:/msys64/mingw64/x86_64-w64-mingw32/include -internal-isystem C:/msys64/mingw64/x86_64-w64-mingw32/usr/include -internal-isystem C:/msys64/mingw64/include -fdebug-compilation-dir=D:/tmp -ferror-limit 19 -fmessage-length=156 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -exception-model=seh -fcolor-diagnostics -faddrsig -o C:/Users/PEEQJH~1/AppData/Local/Temp/main-bad4c9.o -x c main.c
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target x86_64-w64-windows-gnu
ignoring nonexistent directory "C:/msys64/mingw64/x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/msys64/mingw64/x86_64-w64-mingw32/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/msys64/clang64/lib/clang/17/include
 C:/msys64/mingw64/include
End of search list.
 "C:/msys64/clang64/bin/ld.lld" -m i386pep -Bdynamic -o a.exe C:/msys64/mingw64/lib/crt2.o C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o -LC:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0 -LC:/msys64/mingw64/x86_64-w64-mingw32/lib -LC:/msys64/mingw64/x86_64-w64-mingw32/mingw/lib -LC:/msys64/mingw64/lib -LC:/msys64/clang64/lib/clang/17/lib/windows C:/Users/PEEQJH~1/AppData/Local/Temp/main-bad4c9.o -lmingw32 C:/msys64/clang64/lib/clang/17/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 C:/msys64/clang64/lib/clang/17/lib/windows/libclang_rt.builtins-x86_64.a -lunwind -lmoldname -lmingwex -lmsvcrt -lkernel32 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/crtend.o
lld: error: unable to find library -lunwind
lld: error: unable to find library -lunwind
x86_64-w64-mingw32-clang: error: linker command failed with exit code 1 (use -v to see invocation)

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19045

MINGW environments affected

• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANG32
• CLANGARM64

Are you willing to submit a PR?

No response

[revelator]

probably not a good idea to have two different compilers on path in any case.

[huangqinjin]

Yes I agree. The issuse is actually from Windows runners of github actions. C:\Strawberry\c\bin is in PATH, which is a MinGW environment shipped with Strawberry Perl.

@mstorsjo do you have any idea about the issue?

[mstorsjo]

Yes I agree. The issuse is actually from Windows runners of github actions. C:\Strawberry\c\bin is in PATH, which is a MinGW environment shipped with Strawberry Perl.

@mstorsjo do you have any idea about the issue?

I would guess that this is the same issue as #11495.

See https://github.com/llvm/llvm-project/blob/234678fbf9cf05c232221bb8253ed658507f3b49/clang/lib/Driver/ToolChains/MinGW.cpp#L413-L427 (as linked in the issue above) for the logic; when Clang is invoked in mingw mode, it tries to locate the right sysroot. In the case of llvm-mingw, there's a <clang-exe>/../<triple>, e.g. llvm-mingw/x86_64-w64-mingw32 which Clang finds (lines 419-421 above), and Clang knows that this is the right sysroot to use. In the case of the msys2 distributed compilers, since #10634, the headers are all installed in e.g. /clang64/{include,lib}, not /clang64/x86_64-w64-mingw32/{include,lib}. Then Clang is not sure if this base, /clang64, is the real right base to use for everything. E.g. if operating on Unix, with /usr/bin/clang, then when targeting mingw, using /usr/include and /usr/lib is wrong - and then, clang tries to locate a <triple>-gcc in $PATH and look for system libraries next to it - lines 422-424 above. (The actual usecase is more like clang installed in $HOME/clang-build and finding x86_64-w64-mingw32-gcc in /usr/bin.)

CC @mati865; to pick up the discussion from #11495 which I feel was kinda derailed...

When looking at the Clang logic in https://github.com/llvm/llvm-project/blob/234678fbf9cf05c232221bb8253ed658507f3b49/clang/lib/Driver/ToolChains/MinGW.cpp#L413-L427, what if we'd before line 422 would check if e.g. <clang-exe>/../include/_mingw.h or <clang-exe>/../lib/libkernel32.a exists, and then conclude that we're in a setup without the triple prefix, and that <clang-exe>/.. is authoritative and we just should use that rather than looking for <triple>-gcc in $PATH?

[revelator]

That seems very likely.

[mati865]

Yeah, it basically a duplicate.
I have some other things on my TODO list with higher priority but (as bad as it'll sound) I might be able to work on it in the next year.

[huangqinjin]

@mstorsjo Thanks for the details. I've successfully implemented the following workaround on Windows runner.

cmd /c mklink /J C:\msys64\clang64\x86_64-w64-mingw32 C:\msys64\clang64

[mstorsjo]

FWIW, the fix for this landed in upstream Clang in mstorsjo/llvm-project@c671870.

[huangqinjin]

MSYS2 has upgraded to Clang 18.1.2. Thanks the fix by @mstorsjo .