CODEWITHSUNDEEP
c++cmakeprotocol-buffersros
jochemverboom
jochemverboom

Reputation: 21

Trying to compile code with references to both protobuffers 2.6.1 and 3.4.1

I am trying to compile a single codebase with references to both protobuffers 3.4.1 and 2.6.1. Now the 2.6.1 variant is globally defined as I am using ubuntu xenial, also: 

$ protoc --version

yields:

libprotoc 2.6.1

The requirement for protobuffer version 3.4.1 comes from Google Cartographer (https://github.com/googlecartographer/cartographer) while the requirement for 2.6.1 comes from rotors simulator (https://github.com/ethz-asl/rotors_simulator) as it relies on Gazebo-7 (which uses protobuffer 2.6.1). In order to compile Google Cartographer I have added the binaries (added them in a proto3 folder, see below) to the installation by adapting the CMakeList.txt (see original file here: https://raw.githubusercontent.com/googlecartographer/cartographer/master/CMakeLists.txt) for Google Cartographer by adding the following lines:

set(CMAKE_PREFIX_PATH CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/proto3")
...
install(DIRECTORY proto3/ DESTINATION .)

So the binaries of the protobuffer 3.4.1 are added to the install folder. I am utilizing catkin-tools (https://catkin-tools.readthedocs.io/en/latest/) to build the whole workspace. Now in a CMakelist.txt for Rotors Simulator I have the following line:

find_package(Protobuf 2.6.1 REQUIRED HINTS "/usr")

But at the moment while trying to compile it does not seem to be able to find the protobuffer 2.4.1 as it returns the following:

Could not find a configuration file for package "Protobuf" that is
compatible with requested version "2.6.1".

The following configuration files were considered but not accepted:

/home/jochem/catkin_ws/install/lib/cmake/protobuf/protobuf-config.cmake, 
version: 3.4.1

As a side-note, if I compile the packages separately I am able to compile and install the packages. This is done with the following commands:

 catkin build cartographer_ros

and 

 catkin build rotors_gazebo_plugins

I am at the moment trying to adapt the package of rotors_gazebo_plugins but am so far unsuccessful at making sure the correct protobuffer library is selected, am I missing something by defining references to a local protobuffer version?

Upvotes: 1

Views: 571

Answers (2)

EmDroid
EmDroid

Reputation: 6066

If you will be able to wrap up at least one of the libs (i.e. either Cartographer or Rotors or both) into a separate shared library, and if the protobuff is only used internally in each of them, you still might be able to use them both in a single executable by building the shared libs with -fvisibility=hidden gcc flag (to switch the default visibility to hide symbols) and only exporting the symbols that are needed (that the app is using) via __attribute__((visibility("default"))).

This way I recall I was able to use two completely different Boost versions in the past, in the same app (by the shared lib not exporting the boost symbols linked in statically).

Upvotes: 0

Gem Taylor
Gem Taylor

Reputation: 5613

You will find it possible to build a single executable that references 2 versions of the same library on mac, quite difficult on windows, and pretty much impossible on unix. This is because the symbol names are not distinct between the two libraries, so if you load both libraries, there is no way to know which library should service which call.

If you are building 2 different executables in one makefile package, then you just need to set the right libraries to load in the link stage. In linux, libraries are usually installed on your system with a version-number suffix, and a symlink that publishes the latest version without the version number. Normally you simply link to the unsuffixed latest version, but in your case, in your link command you will need to explicitly add the suffix.

If you really do need to link this cobble-together into a single executable, on unix you can do a lot with objcopy --redefine-syms to rename all the entrypoints in one of the libraries, and all the references in the dependant code all after compilation, but before linking. Note that the intended end result is that both libraries will run independently and will not be aware of each other.

Upvotes: 1

Related Questions