This package fails to build on an unstable system. Attached relevant logs and emerge --info
Created attachment 717798 [details] emerge_info emerge --info
Created attachment 717801 [details] freecad-0.19.2-r2:20210623-011716.log build log
This is probably due to using the general find_package call in [1] with vtk-9. The path which looks for specific components[2] doesn't work with vtk-9 any more, because the VTK_MODULES_ENABLED variable is no longer in use, but there is a VTK_AVAILABLE_COMPONENTS exported instead in vtk-config.cmake. I had this on my list when doing the latest bump, but then avoided the patch, because I couldn't find any issues, when the alternate path with the general find_package call without components was used. Thanks for the report. I'm going to test my assumption and report upstream, if I find it's correct.
Sorry, forgot my references... [1] https://github.com/FreeCAD/FreeCAD/blob/0.19.2/cMake/FreeCAD_Helpers/SetupSalomeSMESH.cmake#L45 [2] https://github.com/FreeCAD/FreeCAD/blob/0.19.2/cMake/FreeCAD_Helpers/SetupSalomeSMESH.cmake#L32
*** Bug 798063 has been marked as a duplicate of this bug. ***
While trying to reproduce this, I came about bug #794031. I wonder, how you managed to get this far as to be able to emerge freecad with opencascade-7.5.1 while using vtk-9.
It this still happening with current versions (occ-7.5.2, vtk-9.0.1, freecad-0.19.2-r3)? I can not reproduce this in my test environment. Although the assumptions in my comment #3 seem to be true, vtk-9 is still being correctly detected with the general find_package command, i.e. without specified components and with mpi4py *not* being installed. To me it looks, like already said in comment #6, that you have patched opencascade-7.5.1 yourself with the patch from bug #794031, because your report dates a day before support for vtk-9 has been merged into the tree, and thus were using a non-official and untested combination of packages. If so, please refrain from doing so in the future and verify failures in an environment which uses official package versions only. I'm closing this and ask you to test again with current versions. Feel free to re-open the bug if the issue persists.
(In reply to Bernd from comment #7) > To me it looks, like already said in comment #6, that you have patched > opencascade-7.5.1 yourself with the patch from bug #794031 nope, look at the build log, no user patches applied
For the issue from comment #3, I opened a topic in the forum: https://forum.freecadweb.org/viewtopic.php?f=4&t=60068
(In reply to Alessandro Barbieri from comment #8) > (In reply to Bernd from comment #7) > > To me it looks, like already said in comment #6, that you have patched > > opencascade-7.5.1 yourself with the patch from bug #794031 > > nope, look at the build log, no user patches applied A user patch on opencascade-7.5.1, not freecad.
Created attachment 723250 [details] mypatches.txt my patches
Please, please, don't waste our time by posting your patches. I'm not accusing you of any mistake, and you don't need to defend yourself. I am not attacking you, but only wondering how you were able to build opencascade-7.5.1 against vtk-9 without the patch from bug #794031 being applied. According to that bug, this shouldn't have been possible. But this isn't a bug about OCCT, but about FreeCAD. So, please test, whether the issue still persists or can stay as resolved.
Created attachment 723805 [details] freecad-0.19.2-r3:20210714-081702.log build log
I still have the failure. Should I reopen? -- Found Python3: /usr/bin/python3.10 (found version "3.10.0") found components: Interpreter Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'mpi4py' CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find mpi4py (missing: mpi4py_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /usr/lib64/cmake/vtk-9.0/Findmpi4py.cmake:28 (find_package_handle_standard_args) /usr/lib64/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:303 (find_package) /usr/lib64/cmake/vtk-9.0/vtk-config.cmake:131 (include) cMake/FreeCAD_Helpers/SetupSalomeSMESH.cmake:45 (find_package) CMakeLists.txt:53 (SetupSalomeSMESH) I suspect it's searching mpi4py with the python3.10 implementation but mpi4py is only installed with python3.8 and Python3.9
(In reply to Alessandro Barbieri from comment #14) > > I suspect it's searching mpi4py with the python3.10 implementation but > mpi4py is only installed with python3.8 and Python3.9 I agree. VTK only sets the python major version when searching for an available python interpreter in vtk-config.cmake. Do you have python3.10 set as default python interpreter?
> Do you have python3.10 set > as default python interpreter? My python preferences (eselect python edit) currently are: pypy3 python3.9 python3.8
I renamed /usr/bin/python3.10 before emerging freecad and was able to build it without a problem. Renamed it back afterwards. I know this is just a naive workaround, but cmake is obviously looking for the latest python binary regardless of what is set as system python using eselect because my system python is 3.9.
The error happened today for me when I was preparing a bump for opencascade-7.5.3, although it didn't result in a failed configure phase. The error, however, was emitted by usr/lib64/cmake/vtk-9.0/vtkm/cmake/FindMPI.cmake:1695 (find_package_handle_standard_args), so from a different module inside vtk. Looking at that file, I'm wondering how it would even test for mpi4py, because the main loop only checks for ${LANG} C, CXX and Fortran as far as I can see.
0.19 is no longer in tree, so this has become obsolete. If the issue persists with 0.20, feel free to re-open.
