Björn Piltz
2017-02-06 09:23:59 UTC
Hi,
I'm increasingly often running into problems with Eigen stemming from the
odious ODR and I feel that there should at least be some documentation on
this issue. The problem is that I use Eigen in my C++ projects, but I also
use libraries which in their turn use Eigen. This sometimes leads to
inexplicable crashes if one of the following conditions are met:
1. My code and the library use different versions of Eigen.
2. My code and the library use a different set of compiler flags regarding
SSE, AVX, or different defines regarding alignment, vectorization
Row/Col-order etc
Number 1. can be avoided, even if it is a hassle. For example Ceres uses
the following call
FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} EXACT QUIET)
which is quite a hassle for package maintainers who have to know that they
cannot update a minor version of Eigen without breaking Ceres.
Number 2 can be avoided on Windows if the library is a shared library,
since no Eigen symbols are exported through the DLL .
Is there a preferred way to handle this for the remaing cases? I see two
possible strategies to work around this.
a) Give library authors a standard mechanism to export all relevant compile
flags through defines.
This fixes 2. Then the library user could at least check for compatibility
through some cmake generated header file.
b) Make the Eigen namespace configurable through a define EIGEN_NAMESPACE
which defaults to 'Eigen'.
This might seem a bit intrusive, but it is a simple regex change of the
source code and makes all problems go away. The backside is potential code
bloat if versions and flags do match up.
I am rather partial to alternative b), even if it might still be a good
idea to implement a). At the very least, some documentation for library
authors would be helpful.
Thanks!
---
Best regards,
Björn
I'm increasingly often running into problems with Eigen stemming from the
odious ODR and I feel that there should at least be some documentation on
this issue. The problem is that I use Eigen in my C++ projects, but I also
use libraries which in their turn use Eigen. This sometimes leads to
inexplicable crashes if one of the following conditions are met:
1. My code and the library use different versions of Eigen.
2. My code and the library use a different set of compiler flags regarding
SSE, AVX, or different defines regarding alignment, vectorization
Row/Col-order etc
Number 1. can be avoided, even if it is a hassle. For example Ceres uses
the following call
FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} EXACT QUIET)
which is quite a hassle for package maintainers who have to know that they
cannot update a minor version of Eigen without breaking Ceres.
Number 2 can be avoided on Windows if the library is a shared library,
since no Eigen symbols are exported through the DLL .
Is there a preferred way to handle this for the remaing cases? I see two
possible strategies to work around this.
a) Give library authors a standard mechanism to export all relevant compile
flags through defines.
This fixes 2. Then the library user could at least check for compatibility
through some cmake generated header file.
b) Make the Eigen namespace configurable through a define EIGEN_NAMESPACE
which defaults to 'Eigen'.
This might seem a bit intrusive, but it is a simple regex change of the
source code and makes all problems go away. The backside is potential code
bloat if versions and flags do match up.
I am rather partial to alternative b), even if it might still be a good
idea to implement a). At the very least, some documentation for library
authors would be helpful.
Thanks!
---
Best regards,
Björn