Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem 1
qhullcpp is a static library that had been build with default symbol visibility strategies : all is visible.
When linking against this library, hpp-fcl get all libqhull symbols and also show them as visible.
If a thirdparty library is linking against hpp-fcl and qhullcpp, then a strange symbol mix-up can occur.
I have been able to reproduce it with pinocchio 3.
This can lead to binary conflicts, since there is no guarantee that pinocchio 3 and hpp-fcl are using the same version of qhullcpp with the same ABI (same compiler flags).
Solution
I advise to hide all qhullcpp symbols when linking against it.
I only know how to do it and test it on Linux. We should find a way to fix it on MacOS and Windows if the same issue occur.
Problem 2
hpp-fcl embed qhullcpp source code. This source code is working with some old qhull_r versions. I have not be able to build it with qhull_r 2020.2.
Solution
Maybe we can get rid of it ? Or at least document which version of qhull_r is needed.
If we keep it, then we should find a way to not export the qhullcpp symbol either (probably by creating a static library).