Description of problem: Unable to build a 64-bit application that uses glm imported via a cmake config file as Version-Release number of selected component (if applicable): How reproducible: Build any 64bit cmake project that imports glm using its config (.cmake) files. Steps to Reproduce: 1. Install glm-devel-0.9.9.2-3.fc31.noarch via dnf 2. Create a cmake project that references glm via the command "find_package(glm CONFIG REQUIRED) 3. Run cmake configure (e.g. "cmake -S . -B build") Actual results: Configuration fails and cmake prints the following error: Could not find a configuration file for package "glm" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/share/cmake/glm/glmConfig.cmake, version: 0.9.9 (32bit) -- Configuring incomplete, errors occurred! See also "/home/martin/breakout/build/CMakeFiles/CMakeOutput.log". See also "/home/martin/breakout/build/CMakeFiles/CMakeError.log". Expected results: Configuration should successfully complete (as it does on Fedora 30) Additional info: I think the error is related to the changes in /usr/share/cmake/glm/glmConfigVersion.cmake. Here is the output of diff from between the file from F30 and F31: 20a21,26 > > # if the installed project requested no architecture check, don't perform the check > if("FALSE") > return() > endif() > 22c28 < if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "8" STREQUAL "") --- > if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "4" STREQUAL "") 27,28c33,34 < if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8") < math(EXPR installedBits "8 * 8") --- > if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "4") > math(EXPR installedBits "4 * 8")
I have not yet managed to look at this properly, but my initial guess would be that there is architecture-dependent content in this config file. If so, it should get changed into an arch-dependent package or improved to actually not be architecture-dependent.
Same problem on my Fedora 31. If comment last condition all works. I expect noarch package not relay on arch in it's configurations files. # check that the installed version has the same 32/64bit-ness as the one which is currently searching: if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "4") math(EXPR installedBits "4 * 8") set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)") set(PACKAGE_VERSION_UNSUITABLE TRUE) endif()
Sorry for the slow response. I agree that checking for the matching bitness is wrong. The library is header-only and AFAIK identical for 32 bit and 64 bit targets.
FEDORA-2020-aaa77e2b9d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aaa77e2b9d
FEDORA-2020-84d7cf1fe4 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-84d7cf1fe4
Finally finding some time to work at this I was not able to reproduce this with these: cmake-3.17.1-1.fc31.x86_64 glm-devel-0.9.9.2-3.fc31.noarch My CMakeLists.txt is very simple: project(test3) cmake_minimum_required(VERSION 3.17) find_package(glm CONFIG REQUIRED) include_directories(${GLM_INCLUDE_DIRS}) add_executable(main main.cpp) Main.cpp has simply an empty main(), I don't think its contents matter much at build system generation stage. Regardless, the two updates, FEDORA-2020-aaa77e2b9d and FEDORA-2020-84d7cf1fe4, ship with a patch that uses the recently added cmake feature for disabling the architecture check. The CMake setup used in the 0.9.9.6 package included a workaround for the same purpose, but I am not sure if it worked properly at the time this bug was filed. Would be useful if someone can confirm that the problem still exists in the old code, when using an up-to-date cmake.
FEDORA-2020-84d7cf1fe4 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-84d7cf1fe4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-84d7cf1fe4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-aaa77e2b9d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-aaa77e2b9d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aaa77e2b9d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-aaa77e2b9d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-84d7cf1fe4 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.