CeresConfig.cmake Eigen dependency

[Aditya Gadre]

I am using Ceres on Mac OS X Yosemite. Ceres was installed using MacPorts. Version of Ceres is 1.10.0 and that of Eigen is 3.2.4. The documentation on ceres-solver.org mentions that version of Eigen should be 3.2.1 or higher. The CeresConfig.cmake file however insists on exact Eigen version of 3.2.2. For me, this results in failure of "find_package(Ceres)". I think the following line in CeresConfig.cmake

FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} EXACT QUIET)

should be changed to

FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} QUIET)

Since CERES_EIGEN_VERSION is set to 3.2.2, it will ensure minimum version requirement, but remove the exact match as it is too restrictive.

I would greatly appreciate any input, and may be a better solution that what I have mentioned above.

Thanks!

[Aditya Gadre]

I looked at the ceres-solver source and the cmake/CeresConfig.cmake.in file gets Eigen version during build time. So I think it may be a reasonable idea to change the line

FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} EXACT QUIET)

to

FIND_PACKAGE(Eigen ${CERES_EIGEN_VERSION} QUIET)

in cmake/CeresConfig.cmake.in in ceres-solver source. Please let me know if there is another way of circumventing the issue.

Thanks!

[Sameer Agarwal]

Aditya,

We are working on this, and its a bit of a complicated mess that Keir can explain in detail. 

What the documentation says is that any version of eigen later than 3.2.1 will work, but it does not mean you can compile ceres with one version and use another one when building your application that links into ceres.

Relaxing the version matching constraint can lead to some very hard to debug bugs.  You should use the same version of all dependent libraries that you built ceres with, including eigen. 

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/43dfe964-c5e3-4a68-a988-b152d5b14bbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aditya Gadre]

Thanks Sameer! I will activate eigen 3.2.2 in macports instead of 3.2.4.

- Aditya

[Aditya Gadre]

I initially made it to work by installing Eigen 3.2.2 in MacPorts. My expectation was that since ports are maintained by MacPorts, ceres-solver would be built against the current version of Eigen. However, it does not appear to be the case. So a better solution, than installing different version of Eigen and potentially of other ceres-solver dependencies, is to build ceres-solver from source in MacPorts. By default MacPorts installs a port from binary archive. I ended up using "sudo port install -s ceres-solver", which built ceres-solver against the current versions of all dependencies. There is a small drawback with this approach though - every time a dependency version changes, it will be necessary to rebuild ceres-solver; until MacPorts maintainer of ceres-solver starts rebuilding it in their tree. I hope this solution may be useful to someone in the same situation as I found myself in.

- Aditya

On Saturday, April 4, 2015 at 10:00:06 PM UTC-4, Aditya Gadre wrote:

[Björn Piltz]

Relaxing the version matching constraint can lead to some very hard to debug bugs

I'm very curious about this. Could you explain in a sentence where the problem arises, since one would assume that, Eigen being entirely inline and you never using Eigen containers to pass data between user and library code, it would be safe.

Björn 

--

You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/010f6be2-a058-429c-bbec-c3947e35f0ef%40googlegroups.com.

[Sameer Agarwal]

We have NormalPrior in the public api which takes Eigen matrices and vector as input and is compiled into the library  :/

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAF8Ue3nQYE9HYvAKft8fQLfEs8WfHc6qCCewt90Ko9dua9DuLA%40mail.gmail.com.

[Björn Piltz]

Ok got it. So you just need to inline the NormalPrior ctor and copy the matrices to some internal container. Or just deprecate NormalPrior and add an inline version(to keep the ABI).

Right?

[Keir Mierle]

Hi Björn ,

Without strict checking, there will be violations of the One Definition Rule. The ODR makes transient, internal dependencies hard to deal with, unfortunately, but violating it is the source of real bugs. Here's a Dr. Dobbs article that shows one such case. Unfortunately, when compiling the linker is not always able to enforce the ODR. It happily takes whatever definition is found first on the link command line. With template libraries like Eigen, each translation unit will end up with separate (but identical!) definitions of Eigen functions; so the ODR is not violated. However, if Eigen versions are mixed, than library A can end up with different versions of the same function than library B.

Let me know if this is not clear and I'm happy to expand.

Thanks,

Keir

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAF8Ue3nQYE9HYvAKft8fQLfEs8WfHc6qCCewt90Ko9dua9DuLA%40mail.gmail.com.

[Keir Mierle]

I found another article that talks about other sources of ODR violations, in case anyone is curious.

[Björn Piltz]

Hi Keir,

thanks for explaining!

Those two articles both explicitly say "non inlined" functions, though. But I guess one can't be sure all Eigen functions are actually inlined. Two observations: 

* This problem doesn't exist in shared builds on Windows, so the check is unnecessary there (if NormalPrior gets fixed). How about .so files? Is there any way to make sure the Eigen functions are not exported?

* Checking the version isn't really enough since Eigen's ABI changes depending on #defines regarding SSE, AVX, Row vs Col Major, etc.

My concern isn't theoretical. I had the same problem as Aditya with MacPorts. Since Eigen and Ceres are updated independently - more often than not Ceres just won't work out of the box. So it would be nice to find a solution to this problem.

Thanks for all the great work!

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CADpYijGHKJwk3PTnxtPbCuU5%3DBLvusZc%2BY-ijseOF%3DNuqT9k3A%40mail.gmail.com.

[Keir Mierle]

Hi Björn,

Unfortunately inlining doesn't help since you have to control over which parts of Eigen get inlined. That's a good point that the problem may not exist when using dynamic linking. I've CC'd Nick Lewycky, who is a true expert (unlike me) and may have more insight. You're right about the ABI changes due to Eigen config - not sure what the right solution is there.

Keir

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAF8Ue3m1b9J5No%3D17U%3D3kfiV%3DUBZV9BXTdBD755b%3DCAAx9uECQ%40mail.gmail.com.

[HA]

Hi,

I believe I am getting a similar problem discussed in this thread. I have installed Eigen 3.2.4 on a Mac via brew. When I run my cmake file it says:

CMake Error at /usr/local/share/Ceres/CeresConfig.cmake:85 (MESSAGE):

Failed to find Ceres - Missing required Ceres dependency: Eigen version

3.2.3, please set EIGEN_INCLUDE_DIR.

From the previous posts in this thread I understand that an earlier version of Eigen should be installed? Is this the case here too?

[Alex Stewart]

You could, but it would be better to keep your current Eigen version and rebuild & reinstall Ceres against the new version of Eigen.  The key point is that the installed version of Eigen and the version of Eigen that Ceres was built with have to match:

brew uninstall ceres-solver

brew install ceres-solver --HEAD

should do it.  Without the --HEAD I expect you would probably get a bottle that has been built against an earlier Eigen version to the one you have installed.

-Alex

--

You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/0420483a-99fd-4945-9de1-1c842c3d1fb7%40googlegroups.com.

[HA]

Awesome! It worked. Thank you.