Description of problem: In building FreeCAD from source, which depends on opencascade, it fails to find opencascade libraries which are installed from Fedora packages. If a local build of opencascade is used , it is fine. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. run cmake for a project which includes opencascade ( eg FreeCAD ). 2. cmake -Wno-dev -S~/FreeCAD -DBUILD_QT5=ON -DPYTHON_EXECUTABLE=/usr/bin/python3 3. cmake fails, impossible to build the target project. Actual results: installation directory is incorrectly determined: -- -- Found OCE/OpenCASCADE version: .. -- -- OCE/OpenCASCADE include directory: //include/opencascade -- -- OCE/OpenCASCADE shared libraries directory: //lib64 Expected results: -- -- Found OCE/OpenCASCADE version: 7.5.0 -- -- OCE/OpenCASCADE include directory: /usr/include/opencascade -- -- OCE/OpenCASCADE shared libraries directory: /usr/lib64 Additional info: After debugging this it seems to come from the symlink /lib64->/usr/lib64 on Fedora. The installation directory is sniffed by the OCC cmake files using CMAKE_CURRENT_LIST_FILE. This contains the path of the cmake file itself. If this loaded from a path using the symlink it ends up thinking the libs are installed under / instead of /usr OpenCASCADEConfig.cmake contains the installation sniffer code: the Fedora version adds a test for /lib64 to the upsteam version but does NOT account for symlink. It assumes cmake file loaded from /usr/lib64/cmake instead of /lib64/cmake if (OpenCASCADE_INSTALL_PREFIX MATCHES "/lib$" OR OpenCASCADE_INSTALL_PREFIX MATCHES "/lib64$") get_filename_component (OpenCASCADE_INSTALL_PREFIX "${OpenCASCADE_INSTALL_PREFIX}" PATH) There needs to be an additional test to ensure that OpenCASCADE_INSTALL_PREFIX is not empty at the end of this and to ensure a valid value is returned. This will presumably affect any project including a dependency on opencascade or indeed anything using cmake when run via /lib64 symlink since the fundamental CMAKE_CURRENT_LIST_FILE is incorrectly set.
REAL_PATH could be used to fix this. Available since cmake 3.19, Fed 35 is at 3.22.2 https://cmake.org/cmake/help/latest/command/file.html#real-path
# - in UNIX style: $INSTALL_DIR/lib/cmake/opencascade-<version> # - in Windows style: $INSTALL_DIR/cmake # - in Android style: $INSTALL_DIR/libs/$CMAKE_ANDROID_ARCH_ABI/cmake/opencascade-<version> get_filename_component (OpenCASCADE_INSTALL_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) file (REAL_PATH ${OpenCASCADE_INSTALL_PREFIX} OpenCASCADE_INSTALL_PREFIX) Quick test locally converts it and provides correct paths and allows cmake to continue. Adding DEBUG output before and after that call: DEBUG: sniffer : OpenCASCADE_INSTALL_PREFIX = /lib64/cmake/opencascade DEBUG: sniffer : OpenCASCADE_INSTALL_PREFIX = /usr/lib64/cmake/opencascade -- -- Found OCE/OpenCASCADE version: 7.5.0 -- -- OCE/OpenCASCADE include directory: /usr/include/opencascade -- -- OCE/OpenCASCADE shared libraries directory: /usr/lib64
to make solution in the last post clearer, in the absense of any formatting: near the top of the file OpenCASCADEConfig.cmake, change the second of the following two lines to use REAL_PATH(). This avoids the bug introduced by the symlink of Fedora. get_filename_component (OpenCASCADE_INSTALL_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component (OpenCASCADE_INSTALL_PREFIX "${OpenCASCADE_INSTALL_PREFIX}" PATH) get_filename_component (OpenCASCADE_INSTALL_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) file (REAL_PATH ${OpenCASCADE_INSTALL_PREFIX} OpenCASCADE_INSTALL_PREFIX) This trivial change needs to made inside the build directory once cmake has been run and failed. Someone with cmake skills needs to work out how to make this work without manual editing.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.