I’m investigating packaging python-fcl[1][2] for Fedora, and I find that one of its tests hangs forever. I noticed that upstream builds their wheels for PyPI using a double-precision build of libccd specifically for this reason[3]. It’s unfortunate that libccd doesn’t provide both single-precision and double-precision interfaces, instead offering an ENABLE_DOUBLE_PRECISION CMake option that controls whether the library and headers implement a single-precision or double-precision version of the algorithm. This isn’t very conducive to clean shared-library packaging. I’m curious what you would think about building libccd as double precision (-DENABLE_DOUBLE_PRECISION:BOOL=ON) in Fedora. I’m sure there is some unknown performance impact, but it seems to be feasible. I tested in COPR[4] and was able to successfully rebuild the dependent packages (fcl and gazebo) against the double-precision libccd; I also confirmed this would fix the hanging test in a potential package for python-fcl. Of course, this would be an ABI-breaking change, and dependent packages would need to be rebuilt. Another approach would be to try to build a separate parallel-installable double-precision copy of the libccd library and headers (and link at least fcl against it). This seems trouble-prone, though. Other approaches include: - give up on python-fcl and move on - skip the test and hope it’s not a problem in the real world (hmmm...) - try to bundle both libccd and fcl in python-python-fcl so that I can compile them with a double-precision libccd implementation I’m curious if you have any thoughts on the topic. [1] https://pypi.org/project/python-fcl [2] https://github.com/BerkeleyAutomation/python-fcl [3] https://github.com/BerkeleyAutomation/python-fcl/pull/52 [4] https://copr.fedorainfracloud.org/coprs/music/python-fcl/packages/
I don't have a problem with switching over to double-precision mode if the dependent packages all still work. I don't think it's worth building in both modes unless there's a significant performance hit - we can always go back and add that later.
It looks like fcl and gazebo are still the only dependent packages. I rebuilt everything in the COPR again to see what happened. In Rawhide currently (https://koji.fedoraproject.org/koji/taskinfo?taskID=109620196), with single-precision libccd, there are some fcl test failures that don’t fail the build because the spec file intentionally ignores failures (https://src.fedoraproject.org/rpms/fcl/blob/da461c337c2b82e9aa972df22b524440feb3404c/f/fcl.spec#_68): i686: 90% tests passed, 4 tests failed out of 41 Total Test time (real) = 1571.37 sec The following tests FAILED: 21 - test_fcl_signed_distance (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) 37 - test_gjk_libccd-inl_signed_distance (Timeout) x86_64: 90% tests passed, 4 tests failed out of 41 Total Test time (real) = 1500.11 sec The following tests FAILED: 21 - test_fcl_signed_distance (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) 37 - test_gjk_libccd-inl_signed_distance (Timeout) aarch64: 85% tests passed, 6 tests failed out of 41 Total Test time (real) = 49.25 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 21 - test_fcl_signed_distance (Failed) 29 - test_fcl_octomap_distance (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) 37 - test_gjk_libccd-inl_signed_distance (SEGFAULT) ppc64le: 85% tests passed, 6 tests failed out of 41 Total Test time (real) = 102.54 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 21 - test_fcl_signed_distance (Failed) 29 - test_fcl_octomap_distance (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) 37 - test_gjk_libccd-inl_signed_distance (SEGFAULT) s390x: 83% tests passed, 7 tests failed out of 41 Total Test time (real) = 79.99 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 18 - test_fcl_math (Failed) 21 - test_fcl_signed_distance (Failed) 29 - test_fcl_octomap_distance (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) 37 - test_gjk_libccd-inl_signed_distance (SEGFAULT) ---------------------------------------------------------------------- In COPR with the double-precision libccd (https://copr.fedorainfracloud.org/coprs/music/python-fcl/build/6698770/), the situation is actually a bit better. I didn’t test i686, but: x86_64: 100% tests passed, 0 tests failed out of 41 aarch64: 93% tests passed, 3 tests failed out of 41 Total Test time (real) = 54.20 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) ppc64le: 93% tests passed, 3 tests failed out of 41 Total Test time (real) = 213.19 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 33 - test_gjk_libccd-inl_epa (Failed) 35 - test_gjk_libccd-inl_gjk_doSimplex2 (Failed) s390x: 93% tests passed, 3 tests failed out of 41 Total Test time (real) = 150.00 sec The following tests FAILED: 9 - test_fcl_capsule_capsule (Failed) 18 - test_fcl_math (Failed) 33 - test_gjk_libccd-inl_epa (Failed) ---------------------------------------------------------------------- Meanwhile, gazebo is still in progress (https://copr.fedorainfracloud.org/coprs/music/python-fcl/build/6699041/) but I think it is going to work everywhere. Overall, it looks like there’s no downside to a double-precision libccd except for any possible performance impact, and it actually reduces the number of test failures in fcl.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
(In reply to Rich Mattes from comment #1) > I don't have a problem with switching over to double-precision mode if the > dependent packages all still work. I don't think it's worth building in > both modes unless there's a significant performance hit - we can always go > back and add that later. It seems like this is still a good idea. Should I open a PR?
(In reply to Ben Beasley from comment #0) > - try to bundle both libccd and fcl in python-python-fcl so that I can > compile them with a double-precision libccd implementation I now have a working spec file that bundle libccd and fcl cleanly, almost ready to submit for review, so that takes a lot of pressure off this issue (and provides a path to build the new package in stable releases even if we do make the change to double precision in libccd going forward).
Yes, if you've already got something working go ahead and submit a PR and I'll approve it. We can set up a side tag in rawhide to start with.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-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 '40'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 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 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 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.