Windows-GNU: set CMAKE_DL_LIBS to "dl" on MINGW

Fixes: #17600

---

Cc: @manisandro

assigned to @brad.king

Do: stage

added workflow:nightly-testing label

MSYS2 only provides a libdl.a as part of msys2-runtime-devel, and afaik it's only a stub. MinGW-W32 and MinGW-W64 only have dlfcn to provide libdl, but that's not a regularly installed package.

Well but assuming you are compiling a package which uses dlopen & co. on MinGW, you will need dlfcn (aka https://github.com/dlfcn-win32/dlfcn-win32) in any case.

Correct, but CMAKE_DL_LIBS is used in a lot of CMake packages in a pattern that if it's not empty, append it to the set of libraries. However, for example FindLua does precisely that and Lua does not depend on libdl on Windows.

I'm not saying you're wrong in that CMAKE_DL_LIBS should be set to this value (after all that's what matches the description of the variable), but if we do that, we at least need to change the modules FindLua, FindQt3, Qt4ConfigDependentSettings, FindCUDA and FindLTTngUST to reflect this change for MinGW.

I see it for Qt4ConfigDependentSettings, FindQt3 and FindLua which use CMAKE_DL_LIBS in platform-dependent blocks, but what needs to change in FindLTTngUST and FindCUDA?

Oops, forget about LTTngUST, that's a Linux-specific library.

In FindCUDA, there's one reference to CMAKE_DL_LIBS here. cudart won't be needing libdl on Windows - but CUDA cannot be used with GNU compilers on Windows either, so I suppose it's fine to just ignore that one.

I had just grepped quickly for which of our modules consume CMAKE_DL_LIBS. I think however that cmcurl's CMakeList also requires an adaption.

So I suppose it shouldn't hurt to just take out the respective lines, like

if (CMAKE_DL_LIBS)
  set (QT_LIBRARIES ${QT_LIBRARIES} ${CMAKE_DL_LIBS})
endif ()

out of the platform-specific blocks and have them evaluated unconditionally?

No, the contrary, as long as they're guarded by if(UNIX) logic, it's fine. These libraries after all support using native Windows mechanism instead of dlopen and therefore don't need libdl. From what I can see, the Qt4 and cmcurl occurrences are problematic because they lack such checks.

Uhm I'm confused, is UNIX defined on MINGW? If not I'm not sure I understand what changes need to be done. I though the problem is that blocks like the one in my previous comment weren't evaluated on MINGW because they were guarded by if(UNIX).

Mingw sets WIN32 (because it is just a GCC which compiles to the Windows ABI). Meanwhile, Cygwin sets UNIX since it is a different ABI than Windows. Projects which use dlopen on Mingw should be doing extra logic because Windows doesn't provide such a function out-of-the-box.

That's true, but CMAKE_DL_LIBS is currently being described as "Name of library containing dlopen and dlclose." What libzip does is to use dlfcn.h on MinGW while relying on CMAKE_DL_LIBS for the linking aspect. Given the current documentation, I'd argue that's a valid interpretation of the behavior.

I don't think there's much of a problem setting CMAKE_DL_LIBS to dl for MinGW, but we need to ensure that all occurrences in CMake guard it with if(UNIX) then, if libdl is not needed for the library in question on Windows / MinGW.

Aha so your point is about stuff being compiled via MinGW/Windows but which happen to use GetProcAddress instead of dlopen, right?

Correct. cmcurl falls into that exact category but it uses CMAKE_DL_LIBS unconditionally of UNIX.

Do: unstage

added workflow:wip and removed workflow:nightly-testing labels

Unfortunately this behavior change can break existing projects in cases similar to what @ChrisTX pointed out. For example, CMake's own build breaks with this. See the error here. I tracked it down to this change, which causes a difference. Prior to the change, curl would configure as:

-- Looking for getch in ws2_32;
-- Looking for getch in ws2_32; - found
-- Looking for getch in winmm;ws2_32
-- Looking for getch in winmm;ws2_32 - found

With this change:

-- Looking for getch in ws2_32;dl
-- Looking for getch in ws2_32;dl - not found
-- Looking for getch in winmm;dl
-- Looking for getch in winmm;dl - not found

added 1 commit

• d43baf8b - cmcurl: avoid usage of CMAKE_DL_LIBS on MinGW

Compare with previous version

My analyses:

• FindQt4ConfigDependentSettings: guarded by Q_WS_X11 already
• FindQt3: guarded by if (UNIX)
• FindLua: guarded by if (UNIX)
• FindCuda: relying on the non-support of mingw by CUDA
• FindLTTngUST: this is a find module for a Linux tracing framework; leaving as-is since it probably unconditionally uses dlopen
• cmcurl: updated to avoid its usage on non-UNIX

resolved all discussions

closed

removed workflow:wip label

removed assignee