Can't link with lib files made by MSVC with -static

[kkqy]

MinGW-w64 can link with lib files made by MSVC, but llvm-mingw dosen't support?

[longnguyen2004]

Just to be clear, I've never seen a case where someone would do that. Mixing libraries made by 2 different compilers will potentially causes problems, due to incompatible CRT, debug symbol format, etc etc. With that said, what's the error from the linker?

[kkqy]

Just to be clear, I've never seen a case where someone would do that. Mixing libraries made by 2 different compilers will potentially causes problems, due to incompatible CRT, debug symbol format, etc etc. With that said, what's the error from the linker?

Oh , I just found that the problem is actually that the linker ignore the lib files of DLL if "--static".

I tested mingw-w64, if I set "--static",it will link statically mostly and link agaist libs dynamically if they can't be link statically.
It seems like that llvm-mingw has defferent behavior about this.

[mstorsjo]

Llvm-mingw should be able to link against import libraries made by MSVC just fine. GCC based toolchains (that use binutils for linking) has had some problems with that earlier, but it should work better with recent releases (and there are some fixes that will be part of the next release too).

Mixing toolchains at this level is supposed to work - but if the libraries use different CRTs, and share CRT objects (FILE* etc) across DLL boundaries (or allocate memory with CRT routines in one DLL, and free it in another), or will break.

Mixing static libraries between MSVC and mingw is not supported in general (neither with GCC/binutils based toolchains not with LLVM based ones). It might work by pure luck in some cases, but it can’t be relied upon.

[mstorsjo]

Just to be clear, I've never seen a case where someone would do that. Mixing libraries made by 2 different compilers will potentially causes problems, due to incompatible CRT, debug symbol format, etc etc. With that said, what's the error from the linker?

Oh , I just found that the problem is actually that the linker ignore the lib files of DLL if "--static".

I tested mingw-w64, if I set "--static",it will link statically mostly and link agaist libs dynamically if they can't be link statically. It seems like that llvm-mingw has defferent behavior about this.

To be able to reproduce this issue, you need to tell more exactly what your files are named and exactly what command you execute which behaves differently.

[kkqy]

Just to be clear, I've never seen a case where someone would do that. Mixing libraries made by 2 different compilers will potentially causes problems, due to incompatible CRT, debug symbol format, etc etc. With that said, what's the error from the linker?

Oh , I just found that the problem is actually that the linker ignore the lib files of DLL if "--static".
I tested mingw-w64, if I set "--static",it will link statically mostly and link agaist libs dynamically if they can't be link statically. It seems like that llvm-mingw has defferent behavior about this.

To be able to reproduce this issue, you need to tell more exactly what your files are named and exactly what command you execute which behaves differently.

I am sorry for that.
I know the defferent ABI of defferent toolchain ,but my situation is complex.
because my project use Golang mainly instead of C/C++,
BUT some packages use CGO to link with libraries built by MSVC (I don't have the source of thoese libraries) ,
BUT CGO of Golang only supports GCC-like compiler including LLVM/Clang,
BUT linker of CGO links statically.
so I just described simplely at that time.

The linker of CGO runs the command blow:
"clang++" "-m64" "-mconsole" "-Wl,--tsaware" "-Wl,--nxcompat" "-Wl,--major-os-version=6" "-Wl,--minor-os-version=1" "-Wl,--major-subsystem-version=6" "-Wl,--minor-subsystem-version=1" "-Wl,--dynamicbase" "-Wl,--high-entropy-va" "-o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-build2201061765\\b001\\exe\\a.out.exe" "-Qunused-arguments" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\go.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000000.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000001.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000002.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000003.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000004.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000005.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000006.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000007.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000008.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000009.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000010.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000011.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000012.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000013.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000014.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000015.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000016.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000017.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000018.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000019.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000020.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000021.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000022.o" "C:\\Users\\User\\AppData\\Local\\Temp\\go-link-4058251765\\000023.o" "-g" "-O2" "-static" "-lmd" "-ltrader" "-LD:/Libs/windows/x64" "-g" "-O2" "-g" "-O2" "-Wl,--start-group" "-lmingwex" "-lmingw32" "-Wl,--end-group" "-lkernel32"

and reports error below:

D:\data\project\go\pkg\tool\windows_amd64\link.exe: running clang++ failed: exit status 1
lld: error: unable to find library -lmd
lld: error: unable to find library -ltrader
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

md.lib and trader.lib are placed in D:\Libs\windows\x64 .

I remove the "--static" flag and then it works well.
llvm-mingw has defferent behavior from original MinGW about this:
if "--static" set:

1. Original MinGW would link statically mostly and allow dynamical library too;
2. LLVM-MinGW would link statically only but refuse all lib files of dynamical libraries.

if "--static" not set:

1. Original MinGW will link dynamically such as stdc++ and other runtime.
2. LLVM-MinGW would link statically mostly and allow dynamical library too.

This issue is sovled , but if I need support the two compilers , I have to set defferent flags of linker.

[longnguyen2004]

Sounds like cgo needs to fix that then, anyway glad that your problem is solved.

[mstorsjo]

I observed that GNU ld indeed does look for <libname>.lib (for -l<libname>) even if -static was specified, and dug through the ld sources to figure out why it does that. I posted https://reviews.llvm.org/D135651 with a patch to lld to make it match this behaviour.

I think it'd be good to reopen this bug until this is fixed in a release, but with modified issue subject.

[mstorsjo]

(Sorry, I posted the wrong review url above; I edited the comment above. The correct one is https://reviews.llvm.org/D135651.)

[mstorsjo]

Reopening this again, until the fix is released.

[mstorsjo]

The fix for this issue is now available as the prerelease with LLVM 16.0.0 RC 1 is available: https://github.com/mstorsjo/llvm-mingw/releases/tag/20230130