My system's Eigen does not match the version of Eigen that Ceres was compiled with

[kevi...@insightdigital.org]

Ceres is reporting that my system's Eigen does not match the version of Eigen that Ceres was compiled with:

"Found Eigen dependency, but the version of Eigen found (3.2.5) does not exactly match the version of Eigen Ceres was compiled with (3.2.2).  This can cause subtle bugs by triggering violations of the One Definition Rule."

Since I have installed Eigen 3.2.5 (running Ubuntu), I don't understand is how Ceres is finding Eigen 3.2.2 at all. I'm compiling Ceres against Eigen 3.2.5, from scratch, as per the Ubuntu example here: building Ceres. In that example, Eigen is installed with the following:

sudo apt-get install libeigen3-dev

This installs Eigen 3.2.5 as expected, so I can't yet see where Eigen 3.2.2. enters the picture and how Ceres manages to find it, triggering the conflict.

I have seen that other distros are dealing with this agreement issue (Red Hat Ceres/Eigen agreement).

Any thoughts?

[Sameer Agarwal]

can you share your cmake log? that should tell you which version of eigen and where it is being found.

--
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/b5565a5a-6bb5-41d7-b442-19ffd672e471%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kevi...@insightdigital.org]

Thank you Sameer for your very quick response -- attached is my CMake log; the extracted lines below show Ceres compiling against Eigen v3.2.5:

//Details about finding Eigen
FIND_PACKAGE_MESSAGE_DETAILS_Eigen:INTERNAL=[/usr/include/eigen3][v3.2.5()]

That matches my 'apt-cache' response for 'libeigen3-dev', below:

‘apt-cache showpkg libeigen3-dev’ → version 3.2.5-4

[Alex Stewart]

In your own project which calls find_package(Ceres) and triggers this:

"Found Eigen dependency, but the version of Eigen found (3.2.5) does not exactly match the version of Eigen Ceres was compiled with (3.2.2).  This can cause subtle bugs by triggering violations of the One Definition Rule.”

what is the value of Ceres_DIR in CMake (should be visible in the CMake GUI)?

You can also usually guess this information from the call stack information about the error message which might look something like this (if you are using master - CeresConfig.cmake would be in /usr/local/share/Ceres if you are using the latest stable release):

 Call Stack (most recent call first):

   /usr/local/lib/cmake/Ceres/CeresConfig.cmake:217 (ceres_report_not_found)

   core/CMakeLists.txt:25 (find_package)

What I think has happened is that either:

1) You have a separate build of Ceres that uses Eigen 3.2.2 and was exported by CMake (not installed).

— Check ~/.cmake/packages/Ceres

2) You have an installed version of Ceres that uses Eigen 3.2.2 installed somewhere on the CMake search path ahead of the version you are currently looking at.

Either way, the path to CeresConfig.cmake should highlight what has happened.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/62dd6016-f4dd-4d3f-9231-19bd7c8b84ba%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<Makefile><CMakeCache.txt>

[kevi...@insightdigital.org]

Good points, Lex.

0  To answer your first question, I am setting CERES_ROOT (to my binary path).  I'm setting CERES_ROOT both in CMake's GUI and as an environment variable.  CMake is still unable to find Ceres from the project I'm attempting to build [OpenMVS]); please see the log excerpt below in bold.

1. I see that the user package registry should be in '~/.cmake/packages' as per this Ubuntu manpage, but I can't find ' ~/.cmake/packages/Ceres' (or similar) on my Ubuntu system.  Any advice?

2.  While I can build Ceres without errors, I note that ~/ceres-bin/CeresConfig.cmake is not written, also noted as an error in my CMake configuration log, below.  The above file should be created by Ceres' 'CMakeLists.txt'; has anyone encountered this?

Log excerpt from OpenMVS build via CMake follows:

CMake Error at build/Modules/FindCERES.cmake:31 (include):
include could not find load file:

/home/kevin/ceres-bin/CeresConfig.cmake

Call Stack (most recent call first):

libs/MVS/CMakeLists.txt:15 (FIND_PACKAGE)

CMake Error at build/Utils.cmake:216 (message):
CERES required, but not found: Please specify CERES directory using
CERES_ROOT env. variable

Call Stack (most recent call first):

build/Modules/FindCERES.cmake:102 (package_report_not_found)
libs/MVS/CMakeLists.txt:15 (FIND_PACKAGE)

[Alex Stewart]

So, the core issue is that openMVS is doing things it should not be (at least for any even moderately recent version of Ceres >= 1.8).  It is using a local FindCERES.cmake script here:

https://github.com/cdcseacave/openMVS/blob/d062feb7e3cfb6eddd88cd0ef4a411c752259673/build/Modules/FindCERES.cmake

which is at best redundant, and at worst causes problems as you are finding out.  The best fix for this would be to patch openMVS like so (and submit it back to them):

1) Remove build/Modules/FindCERES.cmake

https://github.com/cdcseacave/openMVS/blob/d062feb7e3cfb6eddd88cd0ef4a411c752259673/build/Modules/FindCERES.cmake

2) Replace lines 15-19 here:

https://github.com/cdcseacave/openMVS/blob/9d67937336a6ab6fe081fcba40b3dfc6d1eb9a7a/libs/MVS/CMakeLists.txt#L15-L19

with this:

find_package(Ceres)

if (Ceres_FOUND)

   include_directories( ${CERES_INCLUDE_DIRS} )

endif()

3) Replace line 40 here:

https://github.com/cdcseacave/openMVS/blob/9d67937336a6ab6fe081fcba40b3dfc6d1eb9a7a/libs/MVS/CMakeLists.txt#L40

with this:

target_link_libraries(MVS Common Math IO ${CERES_LIBRARIES} ${CGAL_LIBS} ${CUDA_LIBRARIES})

This:

CMake Error at build/Modules/FindCERES.cmake:31 (include):
include could not find load file:

/home/kevin/ceres-bin/CeresConfig.cmake
Call Stack (most recent call first):
libs/MVS/CMakeLists.txt:15 (FIND_PACKAGE)

is due to a bug in openMVS FindCERES.cmake - it is forcibly searching for CeresConfig.cmake in the directory you specified when it doesn’t exist - with the fixes above, CMake should correctly find CeresConfig.cmake which can be in one of two places depending on whether Ceres installed or exported:

http://ceres-solver.org/building.html#installing-a-project-with-cmake-vs-exporting-its-build-directory

If Ceres was installed:

1) If you are using master (release >= 1.12): <CERES_INSTALL_ROOT>/lib/cmake/Ceres

— If you are using releases < 1.12: <CERES_INSTALL_ROOT>/share/Ceres

If the Ceres build directory was exported via CMake using the EXPORT_BUILD_DIR option in Ceres: http://ceres-solver.org/building.html#options-controlling-ceres-configuration

2) <CERES_BUILD_DIR>

By default Ceres is not exported, which is why your ~/ceres-bin directory (which appears to be the build directory) does not contain a CeresConfig.cmake.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/a837de35-d982-4e1f-b666-08efea0e2d88%40googlegroups.com.

[kevi...@insightdigital.org]

Thank you Lex for your detailed, clear explanation and for taking the time to investigate OpenMVS, which is really going above and beyond.

As you suggest, I'll fork OpenMVS, make the changes you outline, test, and then send a git pull request to OpenMVS to address this for (many) other users.

[kevi...@insightdigital.org]

I forked OpenMVS and made the changes that Lex suggested:  removing the local 'findCERES.cmake' script and editing 'CMakeLists.txt', as follows:

https://github.com/KevinCain/openMVS/blob/master/libs/MVS/CMakeLists.txt#L15-19

https://github.com/KevinCain/openMVS/blob/master/libs/MVS/CMakeLists.txt#L40

However, I'm still getting the same Make error that I began this thread with:

Make Error at /usr/local/lib/cmake/Ceres/CeresConfig.cmake:88 (message):
 Failed to find Ceres - Found Eigen dependency, but the version of Eigen
 found (3.2.92) does not exactly match the version of Eigen Ceres was
 compiled with (3.2.5).  This can cause subtle bugs by triggering violations
 of the One Definition Rule.  See the Wikipedia article
 http://en.wikipedia.org/wiki/One_Definition_Rule for more details

Call Stack (most recent call first):

 /usr/local/lib/cmake/Ceres/CeresConfig.cmake:204 (ceres_report_not_found)
 libs/MVS/CMakeLists.txt:15 (find_package)

I've rebuilt Ceres via http://ceres-solver.org/building.html, to ~/ceres_build.

Ceres' 'FindEIgen.cmake' already contains the '/usr/include' path where my local /usr/include/eigen3 (Eigen 3.2.92) is found:

https://ceres-solver.googlesource.com/ceres-solver/+/master/cmake/FindEigen.cmake (line 95)

Accordingly, Ceres finds and uses that version, not Eigen 3.2.5:

FIND_PACKAGE_MESSAGE_DETAILS_Eigen:INTERNAL=[/usr/include/eigen3][v3.2.92()]  (My Ceres CMake log is attached)

My system is running Ubuntu 16.04, GCC 503.

[kevi...@insightdigital.org]

It seems I was simply failing to install -- issuing 'sudo make install' seems to have resolved the above version conflict error.

I've sent a pull request with Lex's suggested changes above to Pierre Moulon of OpenMVS.

Thanks once again for all of the help.