Problem with latest indigo release

[toliver]

The latest release for indigo seems to have added the libmongocxx_ros package to the list of packages. https://github.com/ros/rosdistro/commit/35fcd4ef99ce979862358bbfa2075a0b80db8001#diff-4bbb8e35ff5dc5e7f2d7b4d00374533f

Also I've noticed that the version has been bumped to 3.6 which effectively means that it is pointing to the latest kinetic version.

Is that intentional or is it a mistake?

Now we are having a problem when trying to build the indigo-devel branch of moveit: two versions of the mongo driver get installed, one is the mongo-dev package for trusty and the other one is the new libmongocxx_ros package. Moveit is finding libmongocxx_ros first, and it is failing to build,as it is a newer version than the one in mongo-dev.

[hawesie]

Yep, this was purposeful, since we found the kinetic version to be backwards compatible with indigo, which was better than having a mess of packages across the versions. We clearly didn't anticipate this issue though. Is this a source build of moveit alongside a binary install of mongodb_store? /cc @marc-hanheide

[marc-hanheide]

I didn't know moveit uses mongo... Could you point me to a CMakeLists.txt in moveit where mongo client libs are included? We could change the name of the lib in our code, but, in the end, if moveit needs a specific version of the lib (the indigo one is older!) then it should probably contain a version check.

[toliver]

Yes, we are building moveit from source alongside a binary install of mogodb_store.

moveit_ros_warehouse depends on warehouse_ros (see here) and warehouse_ros depends on mongo-dev (the mongo package as released on Ubuntu Trusty) (see here).

That means that anyone trying to build moveit from source on indigo/Trusty will bump into this issue if they also need to have mongodb_store.

I don't think moveit has to specify a specific version of mongo for their indigo-devel branch, as they rely on the latest one released on Trusty.

[marc-hanheide]

OK, I still don't understand why ros_warehouse would find "our" version before the system's version, as it searches system paths first in https://github.com/ros-planning/warehouse_ros/blob/indigo-devel/cmake/FindMongoDB.cmake#L13-L19

Do I understand it right that your also build warehouse_ros from source? If so, can you share you CMakeCache.txt to see which headers and libs it found. Or did you just build moveit_ros_warehouse from source? Does it find the wrong headers or just the wrong library?

We could, of course, change the name of the library in https://github.com/strands-project/mongodb_store/blob/kinetic-devel/libmongocxx_ros/CMakeLists.txt#L48

But that wouldn't solve the problem if it finds the wrong headers.

[toliver]

You are right that ros_warehouse should find the dependencies in the specified order.

But we are not building warehouse_ros from source, only moveit. And it seems that this list of paths to find the includes is not propagated to the packages that depend on warehouse_ros.

In our case it is possible that we can drop the dependency on mongodb_store, as I've realised that our package is not currently using it. But of course that is not a real solution.

[marc-hanheide]

Definitely thanks for making us aware of it. Can you still tell me if it finds the wrong headers, the wrong library, or both?

[toliver]

It definitely finds the wrong header. I'm not sure about the library as I'm struggling to interpret the output files of catkin_make.

You can find the compressed build directory in the following link, in case that helps you.

https://drive.google.com/file/d/0B7wJhvk4Ba2NUl9YRkJIdXJxbFk/view?usp=sharing

[marc-hanheide]

many thanks. @hawesie we might have to put libmongo_cxx into a subdir and rename the library to prevent this. What do you think?

[hawesie]

Since this is really for a package-internal purpose, I think that's fine, assuming catkin exposes the library for linking of dependent packages.

[marc-hanheide]

OK, I have very limited time at the moment to work on this, so if anyone wants to have a go I shall be supportive ;-)

[hawesie]

@toliver does the 0.3.7 release which includes #207 by @furushchev fix your problem?