I am trying to build mariadb client library as a submodule by using add_subdirectory(external/mariadb-connector-c) from my project. When I build standalone mariadb client, everything works fine, however this solution means that I have to link pre-built binaries directly. I would like to avoid this kind of two step build process, but when I try to run cmake from my project, I got a lot of errors related to mariadb plugins:
CMake Error at external/mariadb-connector-c/cmake/install_plugins.cmake:11 (INSTALL):
INSTALL TARGETS given no LIBRARY DESTINATION for module target
"client_ed25519".
Call Stack (most recent call first):
external/mariadb-connector-c/cmake/plugins.cmake:82 (INSTALL_PLUGIN)
external/mariadb-connector-c/plugins/auth/CMakeLists.txt:54 (REGISTER_PLUGIN)
external/mariadb-connector-c/plugins/CMakeLists.txt:7 (INCLUDE)
external/mariadb-connector-c/CMakeLists.txt:403 (INCLUDE)
Here, external/mariadb-connector-c is registered as a git submodule inside of my project repository.
Is there any way to embed mariadb client library as a submodule to make it work by running CMake from my root project or do I have to build it as a standalone project?
It does not work for mee too (linux, cmake-3.10)
I have to set at least SET(INSTALL_PLUGIN x) to avoid cmake errors.
Here is my minimal working example:
# file CMakeLists.txt
PROJECT(my_connector_info)
SET(INSTALL_PLUGINDIR ${CMAKE_BINARY_DIR}) # needed by mariadb-connector-c
add_subdirectory(libs/mariadb-connector-c-3.1.10-src EXCLUDE_FROM_ALL)
add_executable(${PROJECT_NAME} my_connector_info.c)
target_link_libraries(${PROJECT_NAME} mariadbclient)
target_include_directories(${PROJECT_NAME} SYSTEM PRIVATE ${CMAKE_SOURCE_DIR}/libs/mariadb-connector-c-3.1.10-src/include)
target_include_directories(${PROJECT_NAME} SYSTEM PRIVATE ${CMAKE_BINARY_DIR}/libs/mariadb-connector-c-3.1.10-src/include)
/* file my_connector_info.c */
#include <stdio.h>
#include <mysql.h>
int main()
{
printf("info: %s\n", mysql_get_client_info());
return 0;
}
Here's how you build it:
#!/bin/sh
set -eux
(
mkdir -p libs
cd libs
test -e mariadb-connector-c-3.1.10-src.tar.gz || wget https://dlm.mariadb.com/1157459/Connectors/c/connector-c-3.1.10/mariadb-connector-c-3.1.10-src.tar.gz
test -d mariadb-connector-c-3.1.10-src || tar -xzf mariadb-connector-c-3.1.10-src.tar.gz
cd -
)
mkdir -p build
cd build
cmake ..
make
./my_connector_info
output of my_connector_info:
info: 10.5.5
Related
I'm using CMake v3.21.0 to invoke Qt's windeployqt during the install stage by the means of the install(CODE) command as follows:
install(
CODE "
execute_process(
COMMAND \"${CMAKE_COMMAND}\" -E
env PATH=\"${windeployqt_ROOT_DIR}\"
\"${windeployqt_EXECUTABLE}\"
# TODO(2021-08-25 by wolters): This is a different path when CPack is`
# used. How to check for this case and obtain the correct output path?
--dir \"${CMAKE_INSTALL_PREFIX}/${args_INSTALL_SUFFIX}\"
--no-quick-import
--no-system-d3d-compiler
--no-virtualkeyboard
--no-compiler-runtime
--no-webkit2
--no-angle
--no-opengl-sw
--verbose 0
\"\$<TARGET_FILE:${args_TARGET}>\"
)
"
COMPONENT runtime
)
This works fine if installing the project:
cmake --build . --config RelWithDebInfo --target install
But when creating a CPack package the files created by windeployqt are not part of the package (ZIP in this case):
cpack -G ZIP -C RelWithDebInfo -D CPACK_COMPONENTS_ALL="runtime"
I know that the issue is the usage of ${CMAKE_INSTALL_PREFIX} in the CODE.
For the install target this is correct.
For the package target this is not correct. Instead the build directory for the current CPack generator should be used, e.g. ${CMAKE_CURRENT_BINARY_DIR}/_CPack_Packages/win64/ZIP/${CPACK_PACKAGE_FILE_NAME}.
My questions are:
Is there a way to differentiate between install and package target in the CODE section? (pseudo-code: if(CMAKE_IS_PACKAGING))
If there is a way: Is it possible to obtain or dynamically build the directory path to the actual CPack temporary "install" directory?
If both problems can be solved the files generated by windeployqt should be part of the packages generated by CPack.
The variable CMAKE_INSTALL_PREFIX should not be expanded in the CMakeLists.txt, as you are doing. Its actual value at invocation time is available inside the install(CODE) fragments.
Consider the following snippet:
cmake_minimum_required(VERSION 3.21)
project(test NONE)
install(CODE [[message(STATUS "HERE: ${CMAKE_INSTALL_PREFIX}")]])
Note that [[ ... ]] escapes variable expansions (you could also use backslashes). Now if you configure this project with -DCMAKE_INSTALL_PREFIX=/tmp/install, you'll see the message print as you expect.
$ cmake -S . -B build -DCMAKE_INSTALL_PREFIX=/tmp/install
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build
$ cmake --build build/ --target install
[0/1] Install the project...
-- Install configuration: ""
-- HERE: /tmp/install
If you now run the install script again without reconfiguring or rebuilding, it will still work:
$ cmake --install build/ --prefix /tmp/other-prefix
-- Install configuration: ""
-- HERE: /tmp/other-prefix
This is how CPack runs your install rules. It does not use the configuration-time value of CMAKE_INSTALL_PREFIX. It expects your project to be relocatable (i.e. bug-free).
I have a small project with a very simple CMakeLists.txt file. At the bottom of this file, I have the following lines:
set (CMAKE_INSTALL_PREFIX /opt/myprod)
message (STATUS "CMAKE_INSTALL_PREFIX: ${CMAKE_INSTALL_PREFIX}")
install (TARGETS myprod DESTINATION bin)
However, when I run:
sudo make install
I get the following:
[100%] Built target myprod
Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/bin/myprod
-- Up-to-date: /usr/bin/myprod
cmake always puts my executable under /usr/bin when it should be under /opt/myprod/bin.
And, yes, the last line is always repeated. Does anyone know how I can fix this?
Using cmake 3.20.3 on Fedora 34.
Your issue cannot be reproduced with the level of detail you've given:
File CMakeLists.txt:
cmake_minimum_required(VERSION 3.20)
project(myprod)
add_executable(myprod main.cpp)
set(CMAKE_INSTALL_PREFIX /opt/myprod)
message (STATUS "CMAKE_INSTALL_PREFIX: ${CMAKE_INSTALL_PREFIX}")
install (TARGETS myprod DESTINATION bin)
File main.cpp
int main() { return 0; }
Commands:
$ cmake -S . -B build
...
$ cmake --build build/
$ sudo cmake --build build/ --target install
[sudo] password for alex:
[0/1] Install the project...
-- Install configuration: "Release"
-- Installing: /opt/myprod/bin/myprod
$ sudo rm -rf /opt/myprod/
So as you can see, /opt/myprod survived to the final output.
The install() command is responsible for generating the cmake_install.cmake script in the build directory. As far as I know, the very first one reads CMAKE_INSTALL_PREFIX, so you must have another call to install() in your project that you aren't showing us.
Furthermore, you should not set CMAKE_INSTALL_PREFIX inside the CMakeLists.txt; it is designed to be set externally as a cache variable. Hard-coding it is bad because someone else might wish to install your project to a different location besides /opt. Maybe they're on a different operating system or Linux distribution. Maybe even your whims change. In any case, one shouldn't need to edit a file to change the install prefix.
Since you're using CMake 3.20, I strongly encourage you to move such settings to presets.
I have a project whose directory layout looks like:
- src/ #Contains main source code
- ext/ #Contains external libraries and headers from GitHub
- CMakeLists.txt
The problem is that no matter what I do, CMake always seems to pass ext/ to the compiler as a relative path, like this:
/usr/bin/c++ -I../ext mysrc.cpp
I've tried doing both:
include_directories("${PROJECT_SOURCE_DIR}/ext")
include_directories("/home/user/project/ext")
But it doesn't seem to matter. The directory is always passed to -I as ../ext.
Why does this matter? At the end of my build I invoke gcov -r <source file> which tells gcov to generate coverage reports from my source file and any relative paths found within. As a result, gcov is going into ext/ and generating reports for tons of stuff I don't care about and it's taking up a lot of time. If CMake would instead pass in -I/home/user/project/ext then gcov -r would ignore everything in ext/.
As far as I can tell from:
https://cmake.org/cmake/help/v3.13/command/include_directories.html ... this isn't possible, but maybe I'm just missing something?
Edit: This appears to be a problem with specifically the ninja generator. When using the Unix Makefiles generator, everything is passed via absolute paths.
https://gitlab.kitware.com/cmake/cmake/issues/18666
Edit2:
user#antimony:~/cmake_test$ ls
CMakeLists.txt ext src
user#antimony:~/cmake_test$ cat CMakeLists.txt
project(Hello)
add_subdirectory(src)
user#antimony:~/cmake_test$ cat src/CMakeLists.txt
include_directories(
.
${PROJECT_SOURCE_DIR}/ext
)
add_executable(hello_world hello.cpp)
user#antimony:~/cmake_test$ cat src/hello.cpp
#include <useless.h>
int main()
{
hello h;
return 0;
}
user#antimony:~/cmake_test$ cat ext/useless.h
struct hello {
int x;
};
user#antimony:~/cmake_test$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake --version
cmake version 3.13.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
user#antimony:~/cmake_test$ mkdir build && cd build
user#antimony:~/cmake_test/build$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake .. -G Ninja
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
-- Build files have been written to: /home/user/cmake_test/build
user#antimony:~/cmake_test/build$ ninja -v
[1/2] /usr/bin/c++ -I../src/. -I../ext -MD -MT src/CMakeFiles/hello_world.dir/hello.o -MF src/CMakeFiles/hello_world.dir/hello.o.d -o src/CMakeFiles/hello_world.dir/hello.o -c ../src/hello.cpp
[2/2] : && /usr/bin/c++ -rdynamic src/CMakeFiles/hello_world.dir/hello.o -o src/hello_world && :
user#antimony:~/cmake_test/build$ cat build.ninja
# CMAKE generated file: DO NOT EDIT!
# Generated by "Ninja" Generator, CMake Version 3.13
# This file contains all the build statements describing the
# compilation DAG.
...
#############################################
# Order-only phony target for hello_world
build cmake_object_order_depends_target_hello_world: phony || src/CMakeFiles/hello_world.dir
build src/CMakeFiles/hello_world.dir/hello.o: CXX_COMPILER__hello_world ../src/hello.cpp || cmake_object_order_depends_target_hello_world
DEP_FILE = src/CMakeFiles/hello_world.dir/hello.o.d
INCLUDES = -I../src/. -I../ext
OBJECT_DIR = src/CMakeFiles/hello_world.dir
OBJECT_FILE_DIR = src/CMakeFiles/hello_world.dir
TARGET_COMPILE_PDB = src/CMakeFiles/hello_world.dir/
TARGET_PDB = src/hello_world.pdb
# =============================================================================
# Link build statements for EXECUTABLE target hello_world
The example shows what may be considered an in-source build. That is when the build directory is the same or a sub-directory of the src folder (not that there is a hard definition or anything, but this does trigger the ninja issue of using relative paths on the command line). Try mkdir ~/cmake_build && cd ~/cmake_build && cmake ~/cmake_test then it should use absolute paths for everything.
Either way there really isn't a specific way to force one or the other. In general cmake generators will use absolute paths for everything that ends up used on the command line. There seems to be issues with Ninja that prevent the generator from using absolute paths for in-source builds (https://github.com/ninja-build/ninja/issues/1251).
Since yesterday none of my packages containing tests build. Catkin complains it cannot find gtest when using catkin_add_gtests(), since GTEST_FOUND is FALSE. You can see this in the error msg below, with the custom output I added to my CMakeLists. Up to yesterday, GTEST_FOUND was TRUE when catkin_add_gtests() was called.
This is the error I always get. In this case I'm trying to build a mockup package on a clean catkin workspace:
Errors << silly_pkg:cmake /home/paco/catkin_ws2/logs/silly_pkg/build.cmake.002.log
Not searching for unused variables given on the command line.
Re-run cmake no build system arguments
-- Using CATKIN_DEVEL_PREFIX: /home/paco/catkin_ws2/devel/.private/silly_pkg
-- Using CMAKE_PREFIX_PATH: /home/paco/catkin_ws2/devel;/opt/ros/kinetic
-- This workspace overlays: /home/paco/catkin_ws2/devel;/opt/ros/kinetic
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/paco/catkin_ws2/build/silly_pkg/test_results
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.11
-- GTEST_FOUND: FALSE
CMake Warning at /opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:149 (message):
skipping gtest 'test_silly_pkg' in project 'silly_pkg' because gtest was
not found
Call Stack (most recent call first):
/opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:79 (_catkin_add_executable_with_google_test)
/opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:28 (_catkin_add_google_test)
CMakeLists.txt:28 (catkin_add_gtest)
CMake Error at /home/paco/catkin_ws2/src/silly_pkg/CMakeLists.txt:33 (target_link_libraries):
Cannot specify link libraries for target "test_silly_pkg" which is not
built by this project.
-- Configuring incomplete, errors occurred!
See also "/home/paco/catkin_ws2/build/silly_pkg/CMakeFiles/CMakeOutput.log".
See also "/home/paco/catkin_ws2/build/silly_pkg/CMakeFiles/CMakeError.log".
cd /home/paco/catkin_ws2/build/silly_pkg; catkin build --get-env silly_pkg | catkin env -si /usr/bin/cmake /home/paco/catkin_ws2/src/silly_pkg --no-warn-unused-cli -DCATKIN_DEVEL_PREFIX=/home/paco/catkin_ws2/devel/.private/silly_pkg -DCMAKE_INSTALL_PREFIX=/home/paco/catkin_ws2/install; cd -
I am using catkin 0.7.11, libgtest-dev 1.7.0 and cmake 3.5.1. I use ROS Kinetic with Ubuntu 16.04. The only thing I did yesterday was reinstalling ROS Kinetic, but the package versions are exactly the same. Did anybody have this problem? Do you have any ideas on what could be happening?
EDIT 3/09/18:
By comparing with a functional catkin+gtest workspace in a different computer, I found out that the main difference is in the results of /opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake. In the functional workspace, line 292 evaluates to TRUE (gtest/gmock is not a target) while in my workspace it evaluates to FALSE. This is because in my workspace running find_package(GMock QUIET) (line 287) sets gmock and gtest as imported targets, which does not happen in the other computer. Why is this different?
Thanks TikO for your help!
Since you wrote that cmake does not find the libraries and that you have reinstalled Kinetic, I assume that you have a freshly installed machine or wiped out gtest libraries by accident.
If you install libgtest-dev, you only get the sources which you need to build and install like this:
sudo apt-get install libgtest-dev
mkdir /tmp/gtest_build && cd /tmp/gtest_build
cmake /usr/src/gtest
make
#copy or symlink libgtest.a and ligtest_main.a to /usr/lib folder
sudo cp *.a /usr/lib
After this routine, you should be able to build again without cmake complaining.
Optional
If you have limited rights on your machine and you are not allowed to install the libraries in that way, just copy them into some home folder like
mkdir ~/lib && cp *.a ~/lib
But be aware of the fact, that you have to call catkin in the following way:
LIBRARY_PATH=~/lib GTEST_ROOT=~/lib catkin_make
LIBRARY_PATH tells the linker where to find the libraries, while GTEST_ROOT gives cmake the location hints for it's checks.
Reference: https://github.com/tik0/gtest_ros_example
SOLUTION FOUND
gmock and gtest were being set to imported target because the suggested manual compilation of libgtest had created a FindGMock.cmake file inside /usr/share/cmake-3.5/Modules. This file was being called by the find(GMock QUIET)
in catkin_add_gtests(), therefore setting the imported target. Just deleting FindGMock.cmake solved the issue.
I can't get CMake to find threads with a Linaro ARM toolchain (I've tried several different ones). Here's what I've done:
Downloaded the gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf.tar.xz toolchain and extracted to /opt.
Downloaded the corresponding sysroot and extracted to ~/sysroot
I created a Toolchain-Linaro-arm.cmake file that looks like this:
set (CMAKE_SYSTEM_NAME Linux)
include (CMakeForceCompiler)
set (TOOLCHAIN_BASE "/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/")
set (CMAKE_SYSTEM_PROCESSOR armhf-cortexa9)
CMAKE_FORCE_C_COMPILER("${TOOLCHAIN_BASE}/bin/arm-linux-gnueabihf-gcc" GNU)
CMAKE_FORCE_CXX_COMPILER("${TOOLCHAIN_BASE}/bin/arm-linux-gnueabihf-g++" GNU)
set (CMAKE_FIND_ROOT_PATH ${CMAKE_FIND_ROOT_PATH} /home/user/sysroot)
set (CMAKE_SIZEOF_VOID_P 4)
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
I created a minimal example project that uses threads:
~/threadstest $ ls
CMakeLists.txt main.cpp
~/threadstest $ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0.0)
project(threads_test)
add_executable(test main.cpp)
find_package(Threads REQUIRED)
target_link_libraries(test, ${CMAKE_THREAD_LIBS_INIT})
~/threadstest $ cat main.cpp
int main() { }
~/threadstest $ mkdir build; cd build
~/threadstest/build $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-Linaro-arm.cmake ..
CMake Error at /opt/cmake-3.3.1-Linux-x86_64/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/opt/cmake-3.3.1-Linux-x86_64/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
/opt/cmake-3.3.1-Linux-x86_64/share/cmake-3.3/Modules/FindThreads.cmake:205 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:8 (find_package)
~/threadstest/build $ cat CMakeFiles/CMakeError.log
Determining if files pthread.h exist failed with the following output:
Change Dir: /home/user/threadstest/arm/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_37a3c/fast"
/usr/bin/make -f CMakeFiles/cmTC_37a3c.dir/build.make CMakeFiles/cmTC_37a3c.dir/build
make[1]: Entering directory `/home/user/threadstest/arm/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_37a3c.dir/CheckIncludeFiles.c.o
/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc -o CMakeFiles/cmTC_37a3c.dir/CheckIncludeFiles.c.o -c /home/user/threadstest/arm/CMakeFiles/CMakeTmp/CheckIncludeFiles.c
/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc)
make[1]: Leaving directory `/home/user/threadstest/arm/CMakeFiles/CMakeTmp'
make[1]: *** [CMakeFiles/cmTC_37a3c.dir/CheckIncludeFiles.c.o] Error 1
make: *** [cmTC_37a3c/fast] Error 2
Source:
/* */
#include <pthread.h>
int main(void){return 0;}
I know the pthread libraries exist:
$ find ~/sysroot -name "*pthread*"
/home/user/sysroot/usr/lib/libpthread_nonshared.a
/home/user/sysroot/usr/lib/libpthread.so.0
/home/user/sysroot/usr/lib/libpthread-2.19-2014.08-1-git.so
/home/user/sysroot/usr/lib/libpthread_p.a
/home/user/sysroot/usr/lib/libpthread.a
/home/user/sysroot/usr/lib/libpthread.so
/home/user/sysroot/usr/include/bits/pthreadtypes.h
/home/user/sysroot/usr/include/pthread.h
It looks like something is still looking at my native libc and not the cross compiling environment:
/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc -o CMakeFiles/cmTC_37a3c.dir/CheckIncludeFiles.c.o -c /home/user/threadstest/arm/CMakeFiles/CMakeTmp/CheckIncludeFiles.c
/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc: /lib/x86_64-linux-gnu/libc.so.6: version "GLIBC_2.14" not found (required by /opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc)
The root cause of the problem not in pthread library:
The root cause is:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc)
Your compiler is trying to use your local libc.
1) Find libc.so* in downloaded sysroot and check version with the following command:
objdump -p libc.so.6 | grep "Version References:" -A 10
The if everything is ok use this lib (with --sysroot options);
You may try to do it manually:
/opt/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf//bin/arm-linux-gnueabihf-gcc -o CMakeFiles/cmTC_37a3c.dir/CheckIncludeFiles.c.o -c /home/user/threadstest/arm/CMakeFiles/CMakeTmp/CheckIncludeFiles.c --sysroot /home/user/sysroot/
2) Your toolchains probably compiled with differ libc.so version than installed on your system, download appropriate version on your system and use it.