lld failing to cross-compile with libmingw32.a error

[ied206]

Hello, first thanks for your excellent work.
I have come across a weird bug while cross-compiling wimlib with llvm-mingw.

Details

Symptoms

When cross-comping wimlib library with llvm-mingw, ld.lld successfully links libwim.dll file.
But the llvm linker fails to link wimlib-imagex.exe, stating machine type x64 conflicts with x86.

This log is from linking i686 binaries from the x86_64 host. The same happens when I build aarch64 binaries from the same host.

The command line explicitly states to search i686-w64-mingw32/lib path for linking library files, where proper libmsvcrt.a and libmingw32.a is located. It also states -m i386pe to link 32bit x86 PE files. However, lld prints machine type x64 conflicts with x86 error.

> "C:/Joveler/Tools/llvm-mingw/bin/ld.lld" -m i386pe -Bdynamic -o .libs/wimlib-imagex.exe C:/Joveler/Tools/llvm-mingw/i686-w64-mingw32/lib/crt2u.o C:/Joveler/Tools/llvm-mingw/i686-w64-mingw32/lib/crtbegin.o -LC:/msys64/ucrt64/lib -LC:/Joveler/Tools/llvm-mingw/i686-w64-mingw32/lib -LC:/Joveler/Tools/llvm-mingw/i686-w64-mingw32/mingw/lib -LC:/Joveler/Tools/llvm-mingw/lib/clang/16/lib/windows programs/wimlib_imagex-imagex.o programs/wimlib_imagex-imagex-win32.o programs/wimlib_imagex-wgetopt.o ./.libs/libwim.dll.a -lntdll -lmingw32 C:/Joveler/Tools/llvm-mingw/lib/clang/16/lib/windows/libclang_rt.builtins-i386.a -l:libunwind.a -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 C:/Joveler/Tools/llvm-mingw/lib/clang/16/lib/windows/libclang_rt.builtins-i386.a -l:libunwind.a -lmoldname -lmingwex -lmsvcrt -lkernel32 C:/Joveler/Tools/llvm-mingw/i686-w64-mingw32/lib/crtend.o

ld.lld: error: libmingw32.a(lib64_libmingw32_a-udll_argv.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-string-l1-1-0s00092.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-stdio-l1-1-0s00080.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-runtime-l1-1-0s00016.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-runtime-l1-1-0s00036.o): machine type x64 conflicts with x86
ld.lld: error: libmingw32.a(lib64_libmingw32_a-wildcard.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-string-l1-1-0h.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-stdio-l1-1-0h.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-runtime-l1-1-0h.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-string-l1-1-0t.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-stdio-l1-1-0t.o): machine type x64 conflicts with x86
ld.lld: error: libmsvcrt.a(libapi-ms-win-crt-runtime-l1-1-0t.o): machine type x64 conflicts with x86
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)

I have tested other programs such as xz-utils, lz4, zlib with llvm-mingw, and lld succeeded in linking both DLL and EXE files.
wimlib-imagex.exe is the only case where lld fails to link.

I have conducted wimlib support forum for this, but we could not figure out the exact reason why.

What is weirder is that in some environments, LLVM linker successfully builds wimlib-imagex.exe.
Its official Windows build link script uses llvm-mingw to build official ARM64 Windows binaries in CI environment, and it works.

Does ld.lld have a compatibility issue with GNU libtool, or is this a nasty bug?

Tested Environment

• Windows 10 x64 22H2
• Toolchain version: llvm-mingw 20230614

How to reproduce

1. Download and decompress wimlib 1.14.3 source.
2. Install MSYS2, and launch MSYS2 UCRT script.
3. Install MSYS2 packages.
   • pacman -S autotools base-devel nasm
4. Run wimlib-msys2-experiment.sh
   • wimlib-msys2-experiment.sh -a i686 -t $LLVM_MINGW_ROOT_PATH $WIMLIB_SOURCE_PATH
   • This script prints CC invocation commands for debugging purposes.

[alvinhochun]

Your linker command contains -LC:/msys64/ucrt64/lib which I would suspect to be the cause.

[ied206]

Your linker command contains -LC:/msys64/ucrt64/lib which I would suspect to be the cause.

I ran a linker command without -LC:/msys64/ucrt64/lib argument and it was a success.
So the previously installed MSYS2 UCRT toolchain was causing an issue. Thanks for pointing out!

[ied206]

To help further developers who came across from searching, I am leaving the exact cause and a workaround.

Workaround

When invoking wimlib configure, append --libdir="${SRCDIR}". Any empty directory would do the same.

$ cd /c/build/wimlib.1.14.3
$ ./configure --libdir=/c/build/wimlib-1.14.3 --host=aarch64-w64-mingw32 --disable-static

Cause

libtool was appending -LC:/msys64/ucrt64/lib to linker arguments. This argument came from libtool libdir value, which denotes the path its dependency library files would be located.

From libwim.la:

# Directory that this library needs to be installed in:
libdir='/ucrt64/lib'

In Linux, executables refer to fixed rpath to search for .so files. I guess that is the reason why libdir path is added to the executable linker command.
In contrast, Windows executables do not depend on a fixed rpath, so libdir is not that necessary. We can safely neutralize that on llvm-mingw.

Finally, thanks again for your kind troubleshooting!