I have a simple library with unit tests. That library can be built as static linked library or dynamic library. The library builds for Windows, Linux and MacOS.
The library is using CMake (with Qt) and has ctest unit tests.
This is how the library gets build and unit tests are called:
cmake -DCMAKE_BUILD_TYPE=Debug path/to/sources
cmake --build . --target all
cmake --build . --target test
This is all working fine, except for MacOS. When building the library is a dynamic linked library, the unit tests do not find the library.
Start 110: UnitTest
110/119 Test #110: UnitTest.................***Exception: Child aborted 0.01 sec
dyld: Library not loaded: library.dylib
Referenced from: /tmp/build/bin/UnitTest
Reason: image not found
Calling ctest directly or calling the executable directly works fine. Only when calling the test target from cmake, the unit test executable does not find the library.
Setting DYLD_LIBRARY_PATH to the location of the library does not help.
I used install_name_tool to change the path to the library to an absolute path, which fixes the problem.
However, this is only a indicator of the problem, not a solution.
I suspect cmake changes the DYLD_LIBRARY_PATH when calling the test target. Is this true? How should this work?
I suspect cmake changes the DYLD_LIBRARY_PATH when calling the test target. Is this true?
In fact, ctest is used to execute your tests previously described in your CMakeLists.txt and neither cmake or ctest update DYLD_LIBRARY_PATH environment variable.
That said, if you would like to associate a specific test with some environment variable, you could do so by setting the ENVIRONMENT test property. For example:
set_property(TEST ${name} PROPERTY ENVIRONMENT "DYLD_LIBRARY_PATH=/path/to/foo")
To better address your problem, I suggest you do the following:
indicate the version of CMake binaries used
if possible possible, provide a small example allow to reproduce the problem
share the output of these two commands:
(1) ldd /tmp/build/bin/UnitTest
(2) otool -l /tmp/build/bin/UnitTest | grep -A 3 LC_RPATH | grep path
As a side note, consider specifying the type of parameter passed to cmake, prefer -DCMAKE_BUILD_TYPE:STRING=Debug instead of -DCMAKE_BUILD_TYPE=Debug.
Related
I'm using CLion with MinGW-GCC on the Windows-x64 platform - This is the background of the problem.
I was trying to install gtest before. But a lot of confusion arose in the middle.
First time I ran those commands(in googletest-release-1.12.1\) according to the instructions of googletest-release-1.12.1\googletest\README.md:
mkdir build
cd build
cmake ..
But I got error messages like:
CMake Error at CMakeLists.txt:51 (project):
Failed to run MSBuild command:
C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe
to get the value of VCTargetsPath:
Then I changed my last command to
cmake -G "MinGW Makefiles" ..
because I use make provided by MinGW. I don't know whether it's right but, it ran properly.
then I called
make
make install
make ran smoothly. But when I ran make install, I got these messages:
Install the project...
-- Install configuration: ""
-- Installing: C:/Program Files (x86)/googletest-distribution/include
CMake Error at googlemock/cmake_install.cmake:41 (file):
file INSTALL cannot make directory "C:/Program Files
(x86)/googletest-distribution/include": No such file or directory.
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
make: *** [Makefile:109: install] Error 1
I have no idea at all this time. So I changed my way. According to this answer, I copied the whole library into my project and edited CMakeLists.txt like this:
cmake_minimum_required(VERSION 3.23)
project(gtest_study)
set(CMAKE_CXX_STANDARD 20)
add_subdirectory(googletest-release-1.12.1)
include_directories(googletest-release-1.12.1/googletest/include)
include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study gtest gtest_main)
target_link_libraries(gtest_study gmock gmock_main)
So my questions are:
Is there any difference between the two which build it using make and cmake metioned firstly, and just use commands like include_directories and target_link_libraries in CMakeLists.txt? (maybe like .h and .dll file? Or just completely the same? I don't know)
When I use make install to install a library on Windows, what should I do in particular? Specify some directory (I don't know which one) or what?
Although in my system environment I use MinGW-makefile, in CLion which the libraries are eventually used, I use ninja as the generator for CMake (it just comes with CLion, not installed for the system). Do I have to specify it and how? （-G "Ninja"doesn't work in my native env）
The difference between
cmake ..
and
cmake -G "MinGW Makefiles" ..
Is the choice of generator: The former uses the default generator, the latter uses the generator you specified. (cmake --help should put a * next to the default generator.)
Based on the error message I assume this is a visual studio generator and you may not be able to run that one properly from within a MinGW terminal.
In the latter case the default install directory seems to be based on the target OS (Windows) but does not seem to incorporate the fact that you're running from a MinGW terminal where the default install path (C:/Program Files (x86)/googletest-distribution) is not valid.
You could try to fix this by providing it during cmake configuration (passing -D 'CMAKE_INSTALL_PREFIX=/c/Program Files (x86)/googletest-distribution' before the source dir) or by providing the install directory during the installation.
The following process should allow you to install the lib. I'm using my preferred way of building here, i.e. not using build system dependent commands, but using cmake to run the build/install commands. I assume the working directory to be the root directory of the gtest sources:
cmake -G "MinGW Makefiles" -S . -B build
cmake --build build
cmake --install build --prefix '/c/Program Files (x86)/googletest-distribution'
The last command needs to be run with admin privileges, the first 2 I don't recommend running as admin. You could instead install to a directory where you do have the permissions to create directories even without admin privileges.
The difference between using the process described above and using add_subdirectory is that the former results in a installation on the system which can be used via find_package and the google test libs won't be rebuilt for every project where you do this.
...
project(gtest_study)
...
# you may need to pass the install location via -D CMAKE_PREFIX_PATH=<install_location> during configuration for this to work
find_package(GTest REQUIRED)
target_link_libraries(gtest_study PRIVATE GTest::gtest_main GTest::gmock)
The latter builds the google test project as part of your own project build and for every project where you use this approach a seperate version of the google test libs is built. Note: there should be no need to specify the include dirs yourself, since this kind of information is attached to the cmake target and gets applied to the linking target automatically:
#include_directories(googletest-release-1.12.1/googletest/include)
#include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study PRIVATE gtest_main gmock)
As for 3.: The CMake generator used for building GTest should be independent of the generator of the project using it. The thing that's important is that the compilers used by the build systems are compatible. I cannot go into detail about this, since I've never used CLion and therefore have too little knowlege about the compilers used by it. (Personally I'm working with Visual Studio on Windows.)
I have found this library https://github.com/embeddedmz/ftpclient-cpp on GitHub but how to install it on Linux(Ubuntu) is quite obscure.
You will need CMake to generate a makefile for the static library or
to build the tests/code coverage program. Also make sure you have
libcurl and Google Test installed.
You can follow this script
https://gist.github.com/fideloper/f72997d2e2c9fbe66459 to install
libcurl.
This tutorial will help you installing properly Google Test on Ubuntu:
https://www.eriksmistad.no/getting-started-with-google-test-on-ubuntu/
The CMake script located in the tree will produce Makefiles for the
creation of the static library and for the unit tests program.
To create a debug static library and a test binary, change directory
to the one containing the first CMakeLists.txt and :
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE:STRING=Debug
make
It is not clear to me what "to the one containing the first CMakeLists.txt" refers to. Is it the one in the Gtest? The one in Curl? Or What?
After trying both (the Cmake in Gtest and Curl) I still get the error: "No such file or directory" while trying to #include "FTPClient.h" .
UPDATE:
Listing what I am doing:
I did git clone https://github.com/embeddedmz/ftpclient-cpp.git then made the build folder, navigate into it, I tried cmake .. -DCMAKE_BUILD_TYPE:STRING=Debug (this is the literal command I inserted) and I get
Cmake Error at CmakeLists.txt: 27 (add_subdirectory): add_subdirectory given source "TestFTP" which is not an existing directory
So what is wrong so far?
After you build the library, there will be a libftpclient.a generated in your build tree.
You can install it to your system as follows:
In this case, copy libftpclient.a to /usr/local/lib and the two header files in FTP to /usr/local/include.
You should then be able to include the header files by adding the -I/usr/local/include flag and link by adding -L/usr/local/lib -lftpclient.
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.
My need is simple. I have to compile and use googletest on windows using MinGW with msys. Has anyone some experience doing this?
Thanks for answers.
It took me some time but I figured it out. Here is the guide for anyone who face the same problem.
To be able to compile GoogleTest on Windows follow this instructions:
I assume you have MinGW with MSYS istalled.
Download and install CMake from the official site http://www.cmake.org/. Use the Win32 installer
version. Once you have completed the installation process copy executable files from
"xxx/CMake/bin" to "xxx/MinWG/bin".
Download and install Python from http://www.python.org/. Again, the Windows installer does the job
fine.
Once you have completed the installation process copy the "python.exe"
form python folder to
"xxx/MinWG/bin".
Download the latest stable GoogleTest from http://code.google.com/p/googletest/ and unpack it into some folder.
Run MSYS terminal and execute following commands.
cd xxx/gtest-x.x.x
cmake -G "MSYS Makefiles"
make
If you have compilation errors from pthread follow these instructions.
Copy the include folder "xxx/gtest-x.x.x/include" into your MinGW gcc include.
Copy the library files "xxx/gtest-x.x.x/*.a" into your MinGW gcc lib.
When you compile tests add "-lgtest" parameter to gcc.
EDIT
Commentators are right. The coping of executables worked for me but generaly it is not a good practice. Try to use a symbolic link instead.
To build libgtest.a without cmake/python, but only using mingw make, gtest now has a 'make' folder with a plain old makefile in it.
Make sure, mingw\bin is in the path (try running 'g++' or something).
Enter the gtest 'googletest\make' folder and run 'make'.
To test, run 'sample1_unittest' (gtest sample test output should appear).
To generate the library 'libgtest.a', run 'ar -rv libgtest.a gtest-all.o'
The library created is a full static library with no dll's generated.
That should be all.
By the way, this also works for building googlemock, just enter the googlemock folder instead of googletest, and follow the same procedure.
The question was asked in 2011 and answer with most votes is also answered the same year. So, a fresh answer would improve the question effectiveness.
Tools You need & I tested with:
Mingw64 8.0.2
GoogleTest GitHUb Source Code repo branch 1.10.0
CMake 3.20.4
and Windows10
Steps
Install the mingw64 by double clicking and chose the path which does
not have space between directory names e.g. "Program Files"
Open settings of the windows and then search environment variables
and oepn the dialog box to edit the Path environment variable
Add the mingw64/bin directory name in the Windows Path Environment
variable e.g. C:\Users[USERNAME]\mingw64\bin (replace [USERNAME]
with your username e.g. Michael or Lee etc)
Install CMake. It is double click install procedure. Make sure, its
bin directory path is added in the Path Environment Variable.
It would be installed in C:/Program Files/...
Download GoogleTest repo extract it and create a build directory
inside the extracted directory.
Execute the following commands
$ cd build
$ cmake .. -G "MinGW Makefiles"
$ mingw32-make.exe
Copy the four static libraries(*.a) from build directory
[ex: C:\Users[USERNAME]\sourcecodes\googletest-master\build\lib]
into lib of MingW64
[ex: C:\Users[USERNAME]\mingw64\x86_64-w64-mingw32\lib]
Go to the GoogleTest extracted repo, navigate to
[ex
C:\Users[USERNAME]\sourcecodes\googletest-master\googletest\include\gtest]
Copy that whole gtest directory and copy to the folder
C:\Users[USERNAME]\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0\include
You are done to go. You can build and link Googltest with your C++ project. I also paste a CMakelists.txt sample
cmake_minimum_required(VERSION 3.12)
project(ProjectName VERSION 1.0.0 LANGUAGES CXX)
include_directories(include)
set(SOURCES src/library.cpp include/library.h)
add_executable(libabc ${SOURCES})
#############
## Testing ##
#############
enable_testing()
find_library(GTest gtest)
add_executable (unitTest test/unit_test.cpp)
target_link_libraries (unitTest gtest gtest_main)
add_test(AllFactTest unitTest)
I hope it would work.
From the README of https://github.com/google/googletest/tree/master/googletest
:
When building Google Test as a standalone project, the typical workflow starts
with:
mkdir mybuild # Create a directory to hold the build output.
cd mybuild
cmake ${GTEST_DIR} # Generate native build scripts.
If you want to build Google Test's samples, you should replace the last command
with
cmake -Dgtest_build_samples=ON ${GTEST_DIR}
As alternative it is also possible to build googletest using the usual MSYS/Mingw make.
So here is my alternative way:
Make sure MSys/MingW is installed on your Windows and the PATH environment is set to it
Open a cmd window - you can set the PATH explicitly here as well
CD to the unzipped googletest directory
Call configure with sh (part of MSys): sh configure
Call make -> libgtest.a should be built. It is placed in your googletest-directory lib/.libs subdirectory
See README of googletest of how to integrate the libgtest.a to your system. Also see googletest primer in the googletest wiki of how to compile. Alternatively specify the library path for gcc -L<googleTestDir>/lib/.libs and add -lgtest to link with your test project executable.
When using ASSERT_DEATH macro to check for asserts in your tested code (meaning asserts in your lib or application, not in googletest), call SetErrorMode - example main:
#include <windows.h>
#include "gtest/gtest.h"
int main (int argc, char** argv)
{
// this prevents annoying error message boxes popping up
// when assert is called in your program code
SetErrorMode(SEM_NOGPFAULTERRORBOX);
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
You don't need to copy the binaries as long as you have them in your path. Install python and CMake. Test them in your msys (MinGW console)
which cmake
which python
If you see the path, then you have the binaries. If not, add their path to your Environmental Variables>PATH or just update within msys (update installation paths if necessary)
export PATH=$PATH:/c/Program Files (x86)/CMake/bin/cmake.exe:/c/Python27/python.exe
Then you can build as suggested:
cd xxx/gtest-x.x.x
cmake -G "MSYS Makefiles"
make
Test if everything works:
cd make
make
./sample1_unittest.exe
With MSYS2, simply install the mingw-w64-x86_64-gtest package:
pacman -S mingw-w64-x86_64-gtest
Then compile tests with the flags -lgtest -lgtest_main.
I'm facing a problem where I build a shared library and a unit-test executable (which is in a sub directory). I want to execute this test as a POST_BUILD operation for the shared library. So I gave
Add_Custom_Command (TARGET ShLibName POST_BUILD COMMAND unit_test_exe)
CMake throws an error message during generation process:
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"libCUEUtilities" of type SHARED_LIBRARY depends on "UtilitiesUnitTest"
"UtilitiesUnitTest" of type EXECUTABLE depends on "libCUEUtilities"
At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries.
So, how can I achieve what I'm trying to do.
I'm using CMake 2.8.1 (RC3) with VS2005 generator.
Sounds like you want to run a unit test every time the shared library is compiled. Since the test executable already depends on the shared library, you can change the add_custom_command to run once the unit test executable has been built. For example:
add_library(CUEUtilities SHARED ${CUEUTILS_LIBRARY_SOURCES})
add_executable(unit_test_exe ${UNIT_TEST_EXE_SOURCES})
target_link_libraries(unit_test_exe CUEUtilities)
add_custom_command(TARGET unit_test_exe POST_BUILD
COMMAND ${CMAKE_CURRENT_BINARY_DIR}/unit_test_exe)
Changing any of the library sources will cause the library to be recompiled. Since the executable has a dependency on the library, the exe will get relinked, and finally the post-build step will be run again.