The linker fails to recognize DLL shared libraries with CMake about llvm-mingw

[mstorsjo]

Hey, thanks for the toolchain, I found it quite useful!

Great to hear that it's useful for you!

I've encountered a few minor problems with the linker using CMake due to some differences with the original toolchain:

• Using find_library() with target_link_libraries() function to find and link against a static or shared library in CMake leads to the following error: lld-link: error: library.dll: bad file type. Did you specify a DLL instead of an import library?

Hmm, this is tricky. LLD doesn't support passing the name of the DLL itself to the linker for linking, but needs an import library, while GNU ld allows you to provide only a DLL. So far I've only ever heard about one user running into this issue, so so far, the effort needed to implement it hasn't felt justified.

(unlike the original MinGW or MSVC, this toolchain handles only static libraries that way).

I'd be interested in looking at what CMake does for MSVC, and why it can't just do that same thing for both MSVC and MinGW setups.

• Using target_link_libraries(application pthread) function to link against POSIX threads leads to: lld-link: error: undefined symbol: pthread_create while -lpthread argument works just fine.

As I'm only moderately familiar with CMake, could you provide some small sample where I could reproduce these two issues? That'd help me looking into the issue.

[nxrighthere]

The second problem was my mistake, I set pthread for the wrong target... (It works fine, sorry).

As for the first one, here's a sample project: LLVM-MinGW-CMake-Test.zip

With generation from GUI:

And then just make or mingw32-make:

make.zip (The executable from the original MinGW toolchain).

[mstorsjo]

Ok, so yes, if you explicitly point CMake at the DLL file, there's nothing it can do, as LLD doesn't support linking directly against a DLL, it needs an import library, just like it tells you. That's a known limitation compared to GNU binutils, with quite limited impact so far.

I was expecting an issue where CMake's find_library chooses to use a DLL file when it automatically tries to find the library, even though an import library exists next to it.

You said that this works with CMake when using MSVC, when linking to a dyanmic library. I'm fairly sure this exact setup, where you hardcode a path to the DLL, doesn't work for MSVC either - or does it? What's the setup where it does work for MSVC but does not work for llvm-mingw?

I presume that find_library(ENET_SHARED enet) will try to look for a library named enet in the library search path (however that's defined in CMake). I would guess that with MSVC, it looks for libraries named enet.lib, and for MinGW it would look for libraries named libenet.a or libenet.dll.a.

[nxrighthere]

Indeed, the same behavior with MSVC, only static libraries works that way...

Dunno, why GNU linker can link directly against shared libraries while Clang with MSVC requires .lib for definitions, weird. 🤔

Thanks for your help, gonna close this issue then, cheers.