-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix error: redefinition of ‘struct eigenpy::NumpyEquivalentType<... #488
Fix error: redefinition of ‘struct eigenpy::NumpyEquivalentType<... #488
Conversation
Signed-off-by: Shane Loretz <[email protected]>
Signed-off-by: Shane Loretz <[email protected]>
Signed-off-by: Shane Loretz <[email protected]>
@wxmerkt Mind reviewing this one? This bug is causing regressions in Noetic on armhf, and that's blocking the Noetic sync. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for putting this together and the ping. Looks good - let's wait for CI to pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good from my end. @jcarpent is this good to merge?
## [3.8.2] - 2024-08-26 ### Fixed - Fix function signature on Windows (stack-of-tasks/eigenpy#494) ## [3.8.1] - 2024-08-25 ### Fixed - Fix compatibility issue with NumPy 2.x on Windows (stack-of-tasks/eigenpy#492) ## [3.8.0] - 2024-08-14 ### Added - Add compatibility with jrl-cmakemodules workspace (stack-of-tasks/eigenpy#485) - Remove support of Python 3.7 (stack-of-tasks/eigenpy#490) ### Fixed - Remove CMake CMP0167 warnings (stack-of-tasks/eigenpy#487) - Fix compilation error on armhf (stack-of-tasks/eigenpy#488)
## [3.10.0] - 2024-09-26 ### Added - `GenericMapPythonVisitor`/`StdMapPythonVisitor` can now take an extra visitor argument in the `expose()` method, similar to `StdVectorPythonVisitor` ### Changed - Move `GenericMapPythonVisitor` to its own header `eigenpy/map.hpp` - Rename `overload_base_get_item_for_std_map` to `overload_base_get_item_for_map`, move out of `eigenpy::details` namespace - Move `EmptyPythonVisitor` to new header `eigenpy/utils/empty-visitor.hpp` ## [3.9.1] - 2024-09-19 ### Added - Add test returning reference of std::pair stack-of-tasks/eigenpy#503 - Add more general visitor `GenericMapPythonVisitor` for map types test `boost::unordered_map<std::string, int>` stack-of-tasks/eigenpy#504 - Support for non-[default-contructible](https://en.cppreference.com/w/cpp/named_req/DefaultConstructible) types in map types stack-of-tasks/eigenpy#504 - Add type_info helpers stack-of-tasks/eigenpy#502 - Add NumPy 2 support stack-of-tasks/eigenpy#496 ### Changed - Move `StdMapPythonVisitor` out of `eigenpy::python` namespace, which was a mistake stack-of-tasks/eigenpy#504 ## [3.9.0] - 2024-08-31 ### Changed - The `exposeStdVectorEigenSpecificType()` template function now takes the vector allocator as a template parameter stack-of-tasks/eigenpy#500 ### Added - Add bp::dist to std::map converter stack-of-tasks/eigenpy#499 ## [3.8.2] - 2024-08-26 ### Fixed - Fix function signature on Windows stack-of-tasks/eigenpy#494 ## [3.8.1] - 2024-08-25 ### Fixed - Fix compatibility issue with NumPy 2.x on Windows stack-of-tasks/eigenpy#492 ## [3.8.0] - 2024-08-14 ### Added - Add compatibility with jrl-cmakemodules workspace stack-of-tasks/eigenpy#485 - Remove support of Python 3.7 stack-of-tasks/eigenpy#490 ### Fixed - Remove CMake CMP0167 warnings stack-of-tasks/eigenpy#487 - Fix compilation error on armhf stack-of-tasks/eigenpy#488
## [3.10.0] - 2024-09-26 ### Added - `GenericMapPythonVisitor`/`StdMapPythonVisitor` can now take an extra visitor argument in the `expose()` method, similar to `StdVectorPythonVisitor` ### Changed - Move `GenericMapPythonVisitor` to its own header `eigenpy/map.hpp` - Rename `overload_base_get_item_for_std_map` to `overload_base_get_item_for_map`, move out of `eigenpy::details` namespace - Move `EmptyPythonVisitor` to new header `eigenpy/utils/empty-visitor.hpp` ## [3.9.1] - 2024-09-19 ### Added - Add test returning reference of std::pair stack-of-tasks/eigenpy#503 - Add more general visitor `GenericMapPythonVisitor` for map types test `boost::unordered_map<std::string, int>` stack-of-tasks/eigenpy#504 - Support for non-[default-contructible](https://en.cppreference.com/w/cpp/named_req/DefaultConstructible) types in map types stack-of-tasks/eigenpy#504 - Add type_info helpers stack-of-tasks/eigenpy#502 - Add NumPy 2 support stack-of-tasks/eigenpy#496 ### Changed - Move `StdMapPythonVisitor` out of `eigenpy::python` namespace, which was a mistake stack-of-tasks/eigenpy#504 ## [3.9.0] - 2024-08-31 ### Changed - The `exposeStdVectorEigenSpecificType()` template function now takes the vector allocator as a template parameter stack-of-tasks/eigenpy#500 ### Added - Add bp::dist to std::map converter stack-of-tasks/eigenpy#499 ## [3.8.2] - 2024-08-26 ### Fixed - Fix function signature on Windows stack-of-tasks/eigenpy#494 ## [3.8.1] - 2024-08-25 ### Fixed - Fix compatibility issue with NumPy 2.x on Windows stack-of-tasks/eigenpy#492 ## [3.8.0] - 2024-08-14 ### Added - Add compatibility with jrl-cmakemodules workspace stack-of-tasks/eigenpy#485 - Remove support of Python 3.7 stack-of-tasks/eigenpy#490 ### Fixed - Remove CMake CMP0167 warnings stack-of-tasks/eigenpy#487 - Fix compilation error on armhf stack-of-tasks/eigenpy#488
The ROS Noetic armhf build for
eigenpy
is failing - likely caused by #455, and it's causing regressions blocking the Noetic Sync. May I request a release to Noetic when this PR or another fix for the issue is merged?This fixes the issue by using SFINAE and partial template specialization(as suggested here) to remove the specializations of
NumpyEquivalentType<long long>
andNumpyEquivalentType<unsigned long long>
when they're the same asint64_t
anduint64_t
respectively.https://build.ros.org/view/Nbin_ufhf_uFhf/job/Nbin_ufhf_uFhf__eigenpy__ubuntu_focal_armhf__binary/96
I tested that eigenpy builds with this PR on an amd64 machine, but that of course won't show the build failure. Instead I made sure the method for the fix works using godbolt.org with the 32bit
ARM GCC 9.3.0
compiler option with the code below: