Linker error with libboost-filesystem-mt

[lucasb-eyer]

TL;DR: move mongodb_store to the top of your dependency list.

When adding the mongodb_store to your CMakeLists.txt, you might be greeted by

/usr/bin/c++       CMakeFiles/store_detections.dir/src/store_detections.cpp.o  -o /home/beyer/lucas-overlay/devel/lib/strands_head_orientation/store_detections -rdynamic /opt/ros/hydro/lib/libcv_bridge.so /opt/ros/hydro/lib/libopencv_videostab.so.2.4.9 /opt/ros/hydro/lib/libopencv_video.so.2.4.9 /opt/ros/hydro/lib/libopencv_superres.so.2.4.9 /opt/ros/hydro/lib/libopencv_stitching.so.2.4.9 /opt/ros/hydro/lib/libopencv_photo.so.2.4.9 /opt/ros/hydro/lib/libopencv_ocl.so.2.4.9 /opt/ros/hydro/lib/libopencv_objdetect.so.2.4.9 /opt/ros/hydro/lib/libopencv_nonfree.so.2.4.9 /opt/ros/hydro/lib/libopencv_ml.so.2.4.9 /opt/ros/hydro/lib/libopencv_legacy.so.2.4.9 /opt/ros/hydro/lib/libopencv_imgproc.so.2.4.9 /opt/ros/hydro/lib/libopencv_highgui.so.2.4.9 /opt/ros/hydro/lib/libopencv_gpu.so.2.4.9 /opt/ros/hydro/lib/libopencv_flann.so.2.4.9 /opt/ros/hydro/lib/libopencv_features2d.so.2.4.9 /opt/ros/hydro/lib/libopencv_core.so.2.4.9 /opt/ros/hydro/lib/libopencv_contrib.so.2.4.9 /opt/ros/hydro/lib/libopencv_calib3d.so.2.4.9 /opt/ros/hydro/lib/libimage_transport.so -ltinyxml /opt/ros/hydro/lib/libclass_loader.so -lPocoFoundation -ldl /opt/ros/hydro/lib/libroslib.so /opt/ros/hydro/lib/libmessage_filters.so /opt/ros/hydro/lib/libroscpp.so -lboost_signals-mt -lboost_filesystem-mt /opt/ros/hydro/lib/librosconsole.so /opt/ros/hydro/lib/librosconsole_log4cxx.so /opt/ros/hydro/lib/librosconsole_backend_interface.so -llog4cxx -lboost_regex-mt /opt/ros/hydro/lib/libxmlrpcpp.so /opt/ros/hydro/lib/libroscpp_serialization.so /opt/ros/hydro/lib/librostime.so -lboost_date_time-mt -lboost_system-mt -lboost_thread-mt -lpthread /opt/ros/hydro/lib/libcpp_common.so /opt/ros/hydro/lib/libconsole_bridge.so /opt/ros/hydro/lib/libmessage_store.so -Wl,-Bstatic -lmongoclient -Wl,-Bdynamic /home/beyer/lucas-overlay/devel/lib/libopencv_warco.so -Wl,-rpath,/opt/ros/hydro/lib:/home/beyer/lucas-overlay/devel/lib 
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libmongoclient.a(log.o): undefined reference to symbol 'boost::filesystem2::detail::status_api(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::system::error_code&)'
/usr/bin/ld: note: 'boost::filesystem2::detail::status_api(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::system::error_code&)' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_filesystem-mt.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_filesystem-mt.so: could not read symbols: Invalid operation

The important part being undefined reference to symbol 'boost::filesystem2::detail::status_api(...)'. The problem here is that your package is now implicitly linking to libmongoclient.a statically. That one needs to call a function defined in the dynamic library libboost_filesystem-mt.so, which is also added to the linker line.

BUT if some other dependency of yours also needs libboost_filesystem-mt.so, it will be added to the linker line before libmongoclient.a and, for some reason, not added after it again later. For this reason, moving the mongodb_store dependency to the front in your call to catkin's COMPONENTS list fixes that error.

Posting this issue for posteriority, aka. google. (And a slight hope for a better fix.)

[hawesie]

Is there anything we can do in mongodb_store or is this due to the static lib? (which has caused us grief elsewhere)

[lucasb-eyer]

Dynamic lib would be the easy way out. I'd have to play with a minimal example to see for the static case, but I don't really have time in the next two weeks, sorry! I'll post back when/if I do get something.

[marc-hanheide]

We tried many different things today... no other than the fix @lucasb-eyer and I came up with worked. As @lucasb-eyer says, this ticket is more for documentation purposes. With indigo the problem will be gone, because finally mongoclient is dynamic in trusty. So, I close this for now

[lucasb-eyer]

Actually, after a good sleep, no. This happens because the shipped FindMongoDB.cmake doesn't do what it's supposed to do, specifically the first point:

• Use find_package to detect other libraries that the library depends on
  • The arguments QUIETLY and REQUIRED should be forwarded (e.g. if current package was REQUIRED, the depencency should also be)

What currently is MongoDB_LIBRARIES should actually be MongoDB_LIBRARY, and a MongoDB_LIBRARIES which includes all the dependencies (boost-system and boost-filesystem and maybe more) and be used in CMakeList.txts using mongo.

Don't have the time to fix it now, but please re-open the issue.

[marc-hanheide]

Not sure I get it (maybe because I'm still sleep deprived). Are you referring to https://github.com/strands-project/mongodb_store/blob/hydro-devel/mongodb_store/cmake/FindMongoDB.cmake shipped with mongodb_store? The I don't get why you suggest MongoDB_LIBRARY. That isn't defined... Or what don't I get here?

[lucasb-eyer]

Yes, I'm talking about that one. And what I'm saying is that foo_LIBRARY should usually be used for the foo library itself and nothing else, while foo_LIBRARIES should be a list containing the library itself plus its dependencies. In the current version of FindMongoDB.cmake, MongoDB_LIBRARIES is wrongly used for the library only, and nothing contains the library+dependencies. See the official README for more verbose details.

[marc-hanheide]

Well, from the text (quoted from here)

XXX_LIBRARIES The libraries to link against to use XXX. These should include full paths. This should not be a cache entry.

I conclude that indeed it is correct to have libmongoclient.a listed in MongoDB_LIBRARIES. What you are saying is that also the others should be listed here (e.g. boost-filesystem), right?

I think I have to agree on that. The problem is that this is only needed IF libmongoclient is static. So, we need to improve this further, I see. Anyone an expert in cmake to make this work as it should?

[lucasb-eyer]

The first part is right.

The problem is that this is only needed IF libmongoclient is static.

In theory yes, but in practice it doesn't matter since linking to the same dynamic library multiple times is not a problem.

I'm sorry I don't have the time to fix it now ; I'm very "deadlined" these weeks, already spent more worktime on this than I should :-/

[marc-hanheide]

can I assume this is fixed by #105?

[hawesie]

Let's just wait and see. I guess there's a chance I've done something to mess this up.

[lucasb-eyer]

I'll try it next week, I'm in an integration week right now. Edit: is it "in" or "on"?

[marc-hanheide]

is fixed, I assume

[lucasb-eyer]

I completely lost this from my radar and don't know where to test anymore, sorry.