longnguyen2004
commented
2 years ago What's your CMake version?
Closed falhumai96 closed 1 year ago
longnguyen2004
commented
2 years ago What's your CMake version?
mstorsjo
commented
2 years ago I reproduced this issue - it's caused by Fedora applying a custom, nonstandard patch on CMake.
In https://github.com/llvm/llvm-project/blob/llvmorg-14.0.0/openmp/runtime/src/CMakeLists.txt#L150-L153, the OpenMP runtime adds linking against ${CMAKE_DL_LIBS}, with the intent that if the platform requires linking against a non-default library to do dynamic loading, link against that library.
Fedora's CMake packaging includes a patch which sets CMAKE_DL_LIBS to dl on mingw platforms, despite the fact that there's no default shipped dl library on mingw platforms: https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake-mingw-dl.patch
This issue has been discussed and argued upstream in CMake in https://gitlab.kitware.com/cmake/cmake/-/issues/17600 and https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1642. The argument is that CMAKE_DL_LIBS is documented as Name of library containing dlopen and dlclose. - and if you want dlopen/dlclose on mingw, you need a third party library such as https://github.com/dlfcn-win32/dlfcn-win32.
The issue is that lots and lots of cmake code includes CMAKE_DL_LIBS even on platforms where they don't specifically are going to be calling dlopen and dlclose, as noted in the merge request above as it broke lots of code when the patch was tested out - the llvm OpenMP runtime seems to be yet another case of this.
The discussion hinted that third party code shouldn't be including CMAKE_DL_LIBS if they really aren't going to be calling dlopen anyway, and patches were written (but not merged) to this effect as part of that merge request, but the upstream merge request was closed.
Despite this, fedora still carries this disruptive patch downstream.
falhumai96
commented
2 years ago What's your CMake version?
Apologies for the late reply. My CMake version is 3.22.2.
falhumai96
commented
2 years ago I reproduced this issue - it's caused by Fedora applying a custom, nonstandard patch on CMake.
In https://github.com/llvm/llvm-project/blob/llvmorg-14.0.0/openmp/runtime/src/CMakeLists.txt#L150-L153, the OpenMP runtime adds linking against
${CMAKE_DL_LIBS}, with the intent that if the platform requires linking against a non-default library to do dynamic loading, link against that library.Fedora's CMake packaging includes a patch which sets
CMAKE_DL_LIBStodlon mingw platforms, despite the fact that there's no default shippeddllibrary on mingw platforms: https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake-mingw-dl.patchThis issue has been discussed and argued upstream in CMake in https://gitlab.kitware.com/cmake/cmake/-/issues/17600 and https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1642. The argument is that
CMAKE_DL_LIBSis documented asName of library containing dlopen and dlclose.- and if you want dlopen/dlclose on mingw, you need a third party library such as https://github.com/dlfcn-win32/dlfcn-win32.The issue is that lots and lots of cmake code includes
CMAKE_DL_LIBSeven on platforms where they don't specifically are going to be callingdlopenanddlclose, as noted in the merge request above as it broke lots of code when the patch was tested out - the llvm OpenMP runtime seems to be yet another case of this.The discussion hinted that third party code shouldn't be including
CMAKE_DL_LIBSif they really aren't going to be callingdlopenanyway, and patches were written (but not merged) to this effect as part of that merge request, but the upstream merge request was closed.Despite this, fedora still carries this disruptive patch downstream.
I see. So, the best approach now I think is to download a custom CMake, build it, and use it (e.g., by modifying PATH in the build scripts to use the custom one) for building LLVM-MinGW, or there could be instructions on README to use a specific modified CMake for building setup by the developer.
falhumai96
commented
2 years ago I suspected it's a dl wrapper required for MinGW.
mstorsjo
commented
2 years ago I see. So, the best approach now I think is to download a custom CMake, build it, and use it (e.g., by modifying
PATHin the build scripts to use the custom one) for building LLVM-MinGW, or there could be instructions on README to use a specific modified CMake for building setup by the developer.
I guess that's the simplest solution for now. Alternatively, you can patch the openmp code to stop setting CMAKE_DL_LIBS - I posted https://reviews.llvm.org/D130892 which does that, but let's see how it fares.
mstorsjo
commented
2 years ago FWIW, the OpenMP patch was accepted and merged - let's see if I can get it backported into the upcoming 15.0.0 release too.
falhumai96
commented
2 years ago FWIW, the OpenMP patch was accepted and merged - let's see if I can get it backported into the upcoming 15.0.0 release too.
Awesome. I guess we can close this issue once we can build on other distros such as Fedora.
mstorsjo
commented
1 year ago FWIW, the OpenMP patch was accepted and merged - let's see if I can get it backported into the upcoming 15.0.0 release too.
The fix was backported to 15.0.0 in the end: https://github.com/llvm/llvm-project/commit/bab8af8ea062f6332b5c5d13ae688bb8900f244a
Awesome. I guess we can close this issue once we can build on other distros such as Fedora.
Ok, closing it now.
I am using Fedora 36.
Not sure what am I missing. Here is the sample out I get (I stripped the output from
build-all.shto just the output for configuring and building OpenMP):