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.