You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's because pinocchio.cppad doesn't load pycppad as expected.
When building cppad binding, we build the same module.cpp than for the double binding.
Then, both binding can have the same symbols defined.
It's what happen in our example: pinocchio::python::exposeSpecificTypeFeatures for the double binding is loaded instead of the one from cppad binding. Then pycppad is not imported, the AD scalar type is not registered and the code crash.
To avoid this issue we added -fvisibility-inlines-hidden that will set inlined function hidden by default.
But I think we can go further and use -fvisibility=hidden on the whole library.
Since we already manage symbol visibility for Windows, I think it will not cost us so much time.
In stack-of-tasks/eigenpy#444 we fall on this specific issue:
When building cppad Python binding on OSX in Debug mode, running the following code will crash:
It's because pinocchio.cppad doesn't load pycppad as expected.
When building cppad binding, we build the same
module.cpp
than for the double binding.Then, both binding can have the same symbols defined.
It's what happen in our example:
pinocchio::python::exposeSpecificTypeFeatures
for the double binding is loaded instead of the one from cppad binding. Then pycppad is not imported, the AD scalar type is not registered and the code crash.To avoid this issue we added
-fvisibility-inlines-hidden
that will set inlined function hidden by default.But I think we can go further and use -fvisibility=hidden on the whole library.
Since we already manage symbol visibility for Windows, I think it will not cost us so much time.
The main advantage:
-fvisibility-inlines-hidden
make the binary go from 1.2Go to 1GoThe text was updated successfully, but these errors were encountered: