Revision history [back]

Well, it is finding your headers, which is good, because it is getting to the linkedit step, where you get the undefined reference errors.

First thing to check is to run with VERBOSE=1 before your command, e.g. VERBOSE=1 catkin_make. This will cause make to print out the exact commands it is running. Then you can look at the command which does the linking and look for your library in those arguments.

At which point what you put in the ${libfile} CMake variable matters. You said you have .o files? That's pretty strange, usually the arguments to target_link_libraries is either a shared library (object), e.g. .so or a static object archive, e.g. .a. I'm not entirely sure how to integrate existing .o files directly into a new executable created by CMake. I found some links about it here:

http://www.cmake.org/pipermail/cmake/2008-December/025989.html

http://www.cmake.org/pipermail/cmake/2008-November/025541.html

http://stackoverflow.com/questions/14776463/compile-and-add-object-file-from-binary-with-cmake

However, I would push back on the person giving you the .o file and ask for a static library instead (.a). Then you can just put the path to it in for libfile.

One more point is that once you have a library, shared or static, then you can instead put the name of the library, where the name is like /path/to/lib/lib<name>.so. This way it can be either a .so or a .a and can be located in multiple places and CMake will still find the right file. This is the difference in passing /path/to/libmy_library.a to the compiler and passing -lmy_library.

One more point is that you should be installing this library object if you want your install target to work.

If you want to release this package you are working on then you'll need to rethink this whole layout because distributing precomiled binaries is not a great solution for general reuse.