Description of problem: In assimpTargets-release.cmake.in [1], there is an assumption that ASSIMP_LIB_INSTALL_DIR is relative to the prefix. In the spec file, this is configured to %{_libdir}, an absolute path. This results in an invalid ASSIMP_LIBRARY_DIRS value of /usr//usr/lib64. Version-Release number of selected component (if applicable): 5.0.1-2.el8 How reproducible: 100% Steps to Reproduce: 1. grep ASSIMP_LIBRARY_DIRS /usr/lib64/cmake/assimp-5.0/assimpTargets-release.cmake Actual results: set( ASSIMP_LIBRARY_DIRS "${ASSIMP_ROOT_DIR}//usr/lib64") Expected results: set( ASSIMP_LIBRARY_DIRS "${ASSIMP_ROOT_DIR}/lib64") Additional info: Setting the three ASSIMP_*_INSTALL_DIR values to %{_lib}, bin, and include and rebuilding the package fixed the problem for me, but it might be a better idea to just patch assimpTargets-release.cmake.in to expect the absolute paths. I'm not sure which solution you'd prefer, but I'm happy to open a PR if you'd like me to. [1] https://github.com/assimp/assimp/blob/8f0c6b04b2257a520aaab38421b2e090204b69df/assimpTargets-release.cmake.in#L94-L95
It's probably better to update the spec file, it seems we're not using the variables as intended by including absolute paths. I'll update %{_libdir} with %{_lib} and remove the other two, as the defaults are correct.
> It's probably better to update the spec file, it seems we're not using the variables as intended by including absolute paths. I can follow that logic. Thanks for the quick response.
FEDORA-EPEL-2021-fd1b923c69 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fd1b923c69
FEDORA-EPEL-2021-fd1b923c69 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fd1b923c69 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-fd1b923c69 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
I'm afraid that the way this was fixed is not correct, because following: >get_property(LIB64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) > >if ("${LIB64}" STREQUAL "TRUE") > set(LIBSUFFIX 64) >else() > set(LIBSUFFIX "") >endif() will give you "64" as suffix on i686. This is because apparently CMake sets "FIND_LIBRARY_USE_LIB64_PATHS" to "TRUE" by default everywhere. See: https://github.com/Kitware/CMake/blob/bcd98b5f9846d7b9d2a6518501eb7ac56139665e/Modules/Platform/UnixPaths.cmake#L105 I currently hit this issue when trying to use system Assimp in qt6-qt3d where my build fails on i686 for this reason.
Jan, can you confirm that the version in rawhide and f40 no longer suffers from this issue?
(In reply to Scott K Logan from comment #7) > Jan, can you confirm that the version in rawhide and f40 no longer suffers > from this issue? Hi, I tested it and it seems to work now. Thank you.