I'm trying to cross-compile a gRPC using cmake.
I actually managed to do it. Unfortunately my method involves tinkering inside CMakeLists.txt.
Problem was that, when I was trying to compile gRPC it was using protobuffer he just compiled. It cannot run ARM compiled executables on x86 machine.
I managed to compile it by specifying path to protoc and grpc_cpp_plugin manually in gRPCs main CMakeLists.txt. It is dirty and since I would like to include gRPC as submodule I need clean way to do it.
Has anyone managed to cross-compile gRPC using cmake?
This way should work:
Cross-compile Protobuf for target(ARM) and install it.
Make sure that cross-compiled Protobuf can be searched in the toolchain(ARM) you have.
E.g. it is installed into system-default prefix under sysroot.
On host, install Protobuf of the same version. It needn't to be searchable (that is, user-local installation is sufficient).
Cross-compile gRPC with following parameters (set in CMake GUI or as -D option for cmake executable):
gRPC_PROTOBUF_PROVIDER: package
gRPC_PROTOBUF_PACKAGE_TYPE: MODULE
Protobuf_PROTOC_EXECUTABLE: <path to your host protoc executable>
Explanations
Setting parameter gRPC_PROTOBUF_PROVIDER to "package" tells gRPC to not build its own Protobuf, but use already installed variant. This variant is searched by find_package(Protobuf).
Setting parameter gRPC_PROTOBUF_PACKAGE_TYPE to "MODULE" tells gRPC to not use "Config" file, provided by Protobuf installation, for detect Protobuf things (libraries and executable). Config file contains hardcoded paths which cannot be adjusted outside. Instead, FindProtobuf.cmake script is used for find Protobuf.
Setting parameter Protobuf_PROTOC_EXECUTABLE tells FindProtobuf.cmake script to not search Protobuf executable, but takes it from the parameter.
Related
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?
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.
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).
CMake has a find_package() backed by a bunch of FindXYZ scripts (which you can also add to).
What mechanism, if any, is available to me to tell cmake: "Find this package, and if you haven't found it, download it and trigger its build" - with the downloading and building part also backed by per-package scripts or settings (so that downloading could be with wget or git clone, building could be with cmake or maven or a package-specific command, etc.) ?
Yeah, I was bitten by that Friday.
So, CMake has an ExternalProject directive, meant for exactly that, get/update if necessary, configure, build and install this and that external project. Awesome!
Sadly, CMake isn't that awesome.
You can't use the target defined by ExternalProject as a library in target_link_libraries. I've really tried to.
The basic problem is that the updating, building and installation of the external project happens at build time, whereas CMake insists on only using libraries that it found during pre-build (i.e. during the CMake run); you can't re-detect stuff while running make/ninja/msvc… .
You can define a custom target, tell it where the .so you'd want to link against later will be, and try to coerce CMake into believing you without checking at pre-build. Sadly, at least in the CMake versions I had, that broke dependency tracking, so that it simply didn't build the external library, because nothing needed it.
From the error messages you get when trying to use an external project in target_link_library, it seems CMake assumes you'd only want to install tools you need at build time that way, not libraries. A bummer.
You can roll your own version of download-on-demand using execute_process() (which runs on the CMake configure step) with ${CMAKE_COMMAND} as the command invoked on a CMakeLists.txt containing ExternalProject_Add().
You could even either configure_file() the CMakeLists.txt to fill out custom variables or dynamically create the CMakeLists.txt file.
So basically I have the following setup:
A small test library called mylib with an according CMake file. The CMake file creates all the necessary information so that another project (which is going to be my binary) can use find_package to add the library. The library also has a install target.
A small binary called mybin again wih according CMake file which is depended on the mylib project. Using find_package I can add mylib either by specifying the location of the according myLibConfig.cmake (and myLibTargets.cmake etc.) files or by executing the install target of mylib and then letting CMake find the library itself.
Using CMake and XCode everything works like a charm. First, I configure and build the library. Second, I configure my binary project, specify the location of the library and then build it without any problems.
Now I want to do the same using CLion. My problem now is that CLion puts all the generated CMake file (which usually are placed in the build folder) in some cryptic location which can't be changed in the IDE. Now, when I want to build the mybin project I have to specify this cryptic location which seems kinda odd to me (especially because you have to find out first where CLion actually places those files).
So my question is: Is there a more convenient way to handle the described configuration? I guess this is more or less the standard use case which makes me wonder if I'm missing out on something. Being able to specify where CLion should put the generated CMake files would solve my problem I guess.
I know that i can install the library (using the install target) and then let CMake find it. The problem here is that CLion (to my understanding) doesn't support install targets and therefore I have to use (in my case) XCode to build and install the library first.
I was misunderstsanding the intention of find_package(as Tsyvarev pointed out). By using the solution proposed in this question I managed to add an install target to CLion which now allows me to conveniently build "mylib" and use it in the "mybin" project without having to configure anything manually.
I am trying to build libtorrent (http://www.libtorrent.org/) using the provided jamfile. If I try to build it in its vanilla state everything goes well. I am then building using this command:
bjam msvc-12.0 boost=source
However I want to build it with OpenSSL which there seem to be support for. This is where I run into problems. Most likely because it is the first time I use Bjam (actually anything else than make files). I now try to run the following command:
bjam msvc-12.0 boost=source encryption=openssl
Now the compiler starts to complain about not finding the OpenSSL include files.
So I guess I have to include this path in the JAM file. But I have no idea where.
I also tried to add the path into the INCLUDE environment varaible in windows but that doesn't seem to be picked up by BJAM or msvc. Any suggestions?
My understanding of how this is normally done on windows is by installing libraries and headers into visual studio's include and lib folders.
(That's how I install openssl on windows at least).
The jamfile is also supposed to pick up CXXFLAGS and LDFLAGS environment variables, which you could use to introduce the library- and include paths. However, it only does this when boost=system is specified, i.e. you're building against "system" boost libraries instead of from source.
I want to install OpenTissue physics simulation library, and it requires boost.
There is a .bat file in the third_party/include directory which retrieves the required boost bindings. I've successfully ran the script and after that CMake.
However, the CMake 'Configure' states: "Could NOT find boost", even though it is in the directory where the authors of the script supposed it would be. After that, I've tried to manually set the BOOST_BINDING_PATH, as stated here: http://www.opentissue.org/mediawiki/index.php/Boost_bindings. But still, I cannot get the CMake to register the boost bindings.
Has anyone done this successfully?
OS: Windows 8.1
OpenTissue retrieved from: http://www.opentissue.org/svn/OpenTissue/sandbox
CMake: 2.8.12.2
If you know where Boost is, you could pass BOOST_INCLUDE_DIR and BOOST_LIBRARY_DIR when you run CMake, like so:
cmake -DBOOST_INCLUDE_DIR='path_to_boost_headers' -DBOOST_LIBRARY_DIR='path_to_boost_libraries'