Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with latest indigo release #204

Open
toliver opened this issue Oct 9, 2017 · 11 comments
Open

Problem with latest indigo release #204

toliver opened this issue Oct 9, 2017 · 11 comments

Comments

@toliver
Copy link

toliver commented Oct 9, 2017

The latest release for indigo seems to have added the libmongocxx_ros package to the list of packages.
ros/rosdistro@35fcd4e#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
Copy link
Member

hawesie commented Oct 9, 2017

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
Copy link
Member

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
Copy link
Author

toliver commented Oct 10, 2017

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
Copy link
Member

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
Copy link
Author

toliver commented Oct 10, 2017

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
Copy link
Member

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
Copy link
Author

toliver commented Oct 10, 2017

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
Copy link
Member

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
Copy link
Member

hawesie commented Oct 11, 2017

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
Copy link
Member

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
Copy link
Member

hawesie commented Jan 5, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants