I have run into a rather strange problem with Google Tests.
In my project, I am using externalProject_add in order to download google tests and add them into my project. In my function, I believe I am asking for the project to be built, and then installed into a specific directory:
ExternalProject_Add(gTest_download
URL ${GTEST_url}
URL_HASH ${GTEST_hash}
UPDATE_COMMAND ""
BUILD_COMMAND cmake --build . --target install
CMAKE_CACHE_ARGS
-DCMAKE_C_COMPILER:PATH=${Compiler_C}
-DCMAKE_CXX_COMPILER:PATH=${Compiler_CXX}
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=<BINARY_DIR>/installation
)
I can then tell the program where all the source files are living with this:
ExternalProject_Get_Property(gTest_download BINARY_DIR)
set(gTest_LIBRARY_DIR ${BINARY_DIR}/installation/lib CACHE INTERNAL "Google Test Binary Dir")
set(gTest_INCLUDE_DIR ${BINARY_DIR}/installation/include CACHE INTERNAL "Google Test Include Dir")
However, when I try to run a cmake test with protobufs I get the run time error:
./Protobuf_test: error while loading shared libraries: libgmock.so.1.11.0: cannot open shared object file: No such file or directory
Which is super odd, because I know I specifically told the program where to find the libraries in the same externalProject_add file:
set(gTest_LIBRARIES
${gTest_LIBRARY_DIR}/${prefix}gmock${suffix}
${gTest_LIBRARY_DIR}/${prefix}gmock_main${suffix}
${gTest_LIBRARY_DIR}/${prefix}gtest${suffix}
${gTest_LIBRARY_DIR}/${prefix}gtest_main${suffix}
CACHE INTERNAL "Google Test Libraries"
)
Where ${prefix} is "lib" and ${suffix} is ".lib". And I make sure to link them in my CMakeLists.txt file properly by doing target_link_libraries(Protobuf_test ${gTest_LIBRARIES} ${protobuf_LIBRARIES}) ex:
CUSTOM_PROTOBUF_GENERATE_CPP(PROTO_SRCS PROTO_HDS ${CMAKE_CURRENT_LIST_DIR} hello.proto)
include_directories(
${protoBuf_INCLUDE_DIR}
${gTest_INCLUDE_DIR}
${CMAKE_CURRENT_LIST_DIR}
)
add_executable(Protobuf_test protobuf_test.cc ${PROTO_SRCS} ${PROTO_HDS})
add_dependencies(Protobuf_test
gTest_download
protoBuf_download
)
target_link_libraries(Protobuf_test
${gTest_LIBRARIES}
${protoBuf_LIBRARIES}
)
add_test(NAME testing_protobuf COMMAND Protobuf_test)
So I went into the installation folder which is located in d/linuxBuild/lib/src/gTest_download-build/installation/lib and confirmed it exists there. I then ran ldd libgmock.so and got the following output:
libgtest.so.1.11.0 => not found
Which I thought was odd as well. gtest is in the same directory! How is that possible? So I ran ldd on gmock_main:
libgmock.so.1.11.0 => not found
libgtest.so.1.11.0 => not found
So now I have two libraries that are in the same directory however they cannot be found. Confused, I decide to go to where the libraries should have originally installed to and copied over from. So two folders up: d/linuxBuild/lib/src/gTest_download-build. I then go into that folders lib folder and verify the libraries are there. I then run the same ldd command on gmock:
libgtest.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgtest.so.1.11.0 (0x00007fb651729000)
I'm confused by this and again, run it on gmock_main:
libgmock.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgmock.so.1.11.0 (0x00007f58b0db3000)
libgtest.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgtest.so.1.11.0 (0x00007f58b0c9c000)
I am sorry for the lengthy question, but I need to know what happened here? Why is it when I install the libraries the links break from each other and they don't know their locations compared to the ones in the original installation path? Did their symbolic links break? Did I do something incorrectly in the CMake build? I'm scratching my head on this problem since I have never encountered this before. Any advice would be greatly appreciated.
Forget about externalProject_add and use FetchContent / FetchContent_MakeAvailable, especially when dealing with CMake-ready projects:
See https://cmake.org/cmake/help/latest/module/FetchContent.html for details
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
FetchContent_MakeAvailable(googletest)
# ...
target_link_libraries(Protobuf_test
PRIVATE
gmock_main
${protoBuf_LIBRARIES}
)
This way, you are linking against the gmock_main target, which will set up your libraries, includes, and any indirect dependencies correctly like any cmake project added via add_subdirectory() or find_package().
Related
I am trying to link to shared object library (json-c) using cmake. I am a super beginner with cmake, and have tried the solutions in various SO posts to no avail.
I am following the directions laid out here
first step is to build the json-c library, which I did sucesfully.
Second step is linking to it. That's what I am having issues with. After following these instructions, my project directory structure looks like this:
Project Structure (before running make, build directory was empty)
base
|-json-c-master
|-libjson-c.so
|-libjson-c.a
|-json.h
:
:
:
|-CMakeLists.txt
|-Makefile
|-libjson-c.so
|-build
|-CMakeFiles
|-
:
:
|-Makefile.
|-src
|-main.c
|-project1.c
|-project1.h
The contents of my CMakeLists.txt in ~/base/project1/CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(project1) set(CMAKE_CXX_STANDARD 14)
set(SOURCES src/main.c src/project1.h src/project1.c )
add_executable(project1 ${SOURCES})
find_package(json-c CONFIG)
target_link_libraries(${PROJECT_NAME} PRIVATE json-c::json-c)
then, I ran
cd build
cmake -DCMAKE_PREFIX_PATH=/home/<username>/base/project1/json-c-master ..
this populated the previously empty build directory.
then, I ran make
and I got the error that in project1.h, which #includes "json.h", the file "json.h" was not found.
How can I link json.h to project1.h?
I again appreciate your patience, I am a super noob with cmake and I've been pouring over their documentation and other SO posts to no avail.
I want to link expernal 'parquet' project ( https://github.com/apache/arrow/tree/master/cpp ) as part of my current project on Linux.
For this purposes I ran cmake of parquet with such parameters
cd build_parquet
cmake -DCMAKE_BUILD_TYPE=Release -DARROW_PARQUET=ON \
-DBoost_NO_BOOST_CMAKE=TRUE -DBoost_NO_SYSTEM_PATHS=TRUE -DBOOST_ROOT=${BOOST_BUILD_DIR}/include -DBOOST_LIBRARYDIR=${BOOST_BUILD_DIR}/lib/boost -DARROW_BOOST_USE_SHARED=OFF -DBOOST_INCLUDEDIR=${BOOST_BUILD_DIR}/include/boost ..
cmake --build . --config Release
// There are a lot of dependencies except boost, but only boost required to be installed on system, since other could be downloaded and installed by cmake script
Project successfully compiled. I got executable which could launch, generated static libs libarrow.a, libparquet.a, shared libraries libarrow.so, libparquet.so
In my main project I want to use such libraries and I use such commands in cmake to find them
find_path(PARQUET_INCLUDE_DIR NAMES arrow/api.h PATHS ${PARQUET_DIR}/src)
find_library(PARQUET_LIBRARY_RELEASE NAMES parquet.a
PATHS build_parquet/release/Release/ )
find_library(ARROW_LIBRARY_RELEASE NAMES arrow.a
PATHS build_parquet/release/Release/ )
set(PARQUET_LIBRARIES_RELEASE ${PARQUET_LIBRARY_RELEASE} ${ARROW_LIBRARY_RELEASE} )
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Parquet DEFAULT_MSG PARQUET_INCLUDE_DIR
${PARQUET_LIBRARIES_RELEASE } )
That's work okay, libraries and includes are found.
Then I link this libraries to my project
target_link_libraries(${myExe} ${PARQUET_LIBRARIES_RELEASE} ${mySomeOtherLibraries} )
after this I got enormous amount of linker errors such that
libparquet.a(column_writer.cc.o): In function `apache::thrift::transport::TMemoryBuffer::~TMemoryBuffer()':
column_writer.cc:(.text._ZN6apache6thrift9transport13TMemoryBufferD0Ev[_ZN6apache6thrift9transport13TMemoryBufferD5Ev]+0x3): undefined reference to `vtable for apache::thrift::transport::TMemoryBuffer'
.....
so that's what I don't understand much, why lib compiled well in parquet project itself but has a lot of unresolved now, when I use it to link in my own project? Moreover I compiled project for windows and when I did the same things, but with arrow.lib and parquet.lib (instead of libparquet.a and libarrow.a ) things worked fine! I was needed only to put arrow.dll, parquet.dll to executables to run project. But in Linux I've already crashed my head
So, why it doesn't work, what I should do to finally link the project with library ?
Update
I found the problem, I had to link libraries with adding .so files (not only .a files) like this
find_library(PARQUET_LIBRARY_RELEASE NAMES parquet.so parquet.a
PATHS build_parquet/release/Release/ )
find_library(ARROW_LIBRARY_RELEASE NAMES arrow.so arrow.a
PATHS build_parquet/release/Release/ )
set(PARQUET_LIBRARIES_RELEASE ${PARQUET_LIBRARY_RELEASE} ${ARROW_LIBRARY_RELEASE} )
Project is builded. So now the question is, why I need to add .so files to linker (in Windows only static .lib are enough), is it always a case when I build project in Linux ? Is order of linkage important ( .so files first and .a files next ? )
As Uwe wrote in a comment, the https://github.com/apache/parquet-cpp repository is deprecated, and the Parquet C++ library is being developed as part of the Apache Arrow C++ codebase https://github.com/apache/arrow/tree/master/cpp. Can you try building based on that, and if you have trouble can you post on the dev#arrow.apache.org mailing list?
You have succeed to build the project when link with the shared (.so) libraries instead of the static (.a) ones.
(The command find_library actually looks for one library, which name is listed in NAMES option. In your case it found .so library because its name comes before the .a one).
Actually, both shared and static parquet libraries contain the same set of symbols, and both sets are insufficient for link. The difference is that the shared library contains information, where to find remaining symbols (in the thrift library in your case), but the static library doesn't.
For correctly link with the static libraries, you need to list dependent libraries manually.
On Windows .lib file may mean either a static library, or a import file for the shared (.dll) one. It seems that you link with the dynamic one (it has no lib prefix), which succeed like on Linux.
I'm new to CMake. I copied a small vtk example from the link http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/SimplePointsReader and used CMake to compile. And it gives me an error, " Error in configuration process, Project files may be invalid".
It shows me the errors,
CMake Error at CMakeLists.txt:5 (find_package): By not providing
"FindVTK.cmake" in CMAKE_MODULE_PATH this project has asked CMake to
find a package configuration file provided by "VTK", but CMake did
not find one.
Could not find a package configuration file provided by "VTK" with
any of the following names:
VTKConfig.cmake
vtk-config.cmake
Add the installation prefix of "VTK" to CMAKE_PREFIX_PATH or set
"VTK_DIR" to a directory containing one of the above files. If
"VTK" provides a separate development package or SDK, be sure it has
been installed.
I have already installed vtk in my pc and please help me with this problem.
CMakeLists.txt contains the following code
cmake_minimum_required(VERSION 2.8)
PROJECT(SimplePointsReader)
find_package(VTK REQUIRED)
include(${VTK_USE_FILE})
add_executable(SimplePointsReader MACOSX_BUNDLE SimplePointsReader)
if(VTK_LIBRARIES)
target_link_libraries(SimplePointsReader ${VTK_LIBRARIES})
else()
target_link_libraries(SimplePointsReader vtkHybrid vtkWidgets)
endif()
I've solved this problem by setting VTK_DIR=path_to_VTK/bin as an environment variable, because CMakeList.txt file's changing was not helpful.
I have a CMake module to locate FreeGLUT:
FIND_PATH(FREEGLUT_INCLUDE_DIR NAMES GL/freeglut.h)
FIND_LIBRARY(FREEGLUT_LIBRARY NAMES freeglut freeglut_static)
SET(FREEGLUT_LIBRARIES ${FREEGLUT_LIBRARY})
SET(FREEGLUT_INCLUDE_DIRS ${FREEGLUT_INCLUDE_DIR})
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(FreeGLUT DEFAULT_MSG FREEGLUT_LIBRARY FREEGLUT_INCLUDE_DIR)
MARK_AS_ADVANCED(FREEGLUT_INCLUDE_DIR FREEGLUT_LIBRARY)
It works fine and locates freeglut_static.lib when I generate NMake Makefiles on Windows. I'm attempting to statically link FreeGLUT into my DLL:
FIND_PACKAGE(FreeGLUT REQUIRED)
ADD_LIBRARY(vti SHARED ${VTI_SOURCES})
ADD_DEFINITIONS("-DBUILD_VTI=1 -DFREEGLUT_STATIC=1")
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include ${FREEGLUT_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(vti ${FREEGLUT_LIBRARIES})
My source code builds correctly, but when it gets to the linking stage, VC++ fails with:
LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
Which is strange since freeglut.lib isn't mentioned anywhere that I can see in the generated NMake makefiles. It should be trying to link with freeglut_static.lib, which CMake locates and sets in FREEGLUT_LIBRARIES.
What might be causing this?
This is caused with pragma directives in FreeGLUT code (see freeglut_std.h). Using FREEGLUT_STATIC should really fix that for you, but I think you should pass it to CMake without quotes: ADD_DEFINITIONS(-DBUILD_VTI -DFREEGLUT_STATIC)
I guess this would be a generic question on including libraries with existing makefiles within cmake; but here's my context -
I'm trying to include scintilla in another CMake project, and I have the following problem:
On Linux, scintilla has a makefile in (say) the ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk directory; if you run make in that directory (as usual), you get a ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/bin/scintilla.a file - which (I guess) is the static library.
Now, if I'd try to use cmake's ADD_LIBRARY, I'd have to manually specify the sources of scintilla within cmake - and I'd rather not mess with that, given I already have a makefile. So, I'd rather call the usual scintilla make - and then instruct CMAKE to somehow refer to the resulting scintilla.a. (I guess that this then would not ensure cross-platform compatibility - but note that currently cross-platform is not an issue for me; I'd just like to build scintilla as part of this project that already uses cmake, only within Linux)
So, I've tried a bit with this:
ADD_CUSTOM_COMMAND(
OUTPUT scintilla.a
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... but then, add_custom_command adds a "target with no output"; so I'm trying several approach to build upon that, all of which fail (errors given as comment):
ADD_CUSTOM_TARGET(scintilla STATIC DEPENDS scintilla.a) # Target "scintilla" of type UTILITY may not be linked into another target.
ADD_LIBRARY(scintilla STATIC DEPENDS scintilla.a) # Cannot find source file "DEPENDS".
ADD_LIBRARY(scintilla STATIC) # You have called ADD_LIBRARY for library scintilla without any source files.
ADD_DEPENDENCIES(scintilla scintilla.a)
I'm obviously quote a noob with cmake - so, is it possible at all to have cmake run a pre-existing makefile, and "capture" its output library file, such that other components of the cmake project can link against it?
Many thanks for any answers,
Cheers!
EDIT: possible duplicate: CMake: how do i depend on output from a custom target? - Stack Overflow - however, here the breakage seems to be due to the need to specifically have a library that the rest of the cmake project would recognize...
Another related: cmake - adding a custom command with the file name as a target - Stack Overflow; however, it specifically builds an executable from source files (which I wanted to avoid)..
You could also use imported targets and a custom target like this:
# set the output destination
set(SCINTILLA_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk/scintilla.a)
# create a custom target called build_scintilla that is part of ALL
# and will run each time you type make
add_custom_target(build_scintilla ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target")
# now create an imported static target
add_library(scintilla STATIC IMPORTED)
# Import target "scintilla" for configuration ""
set_property(TARGET scintilla APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(scintilla PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${SCINTILLA_LIBRARY}")
# now you can use scintilla as if it were a regular cmake built target in your project
add_dependencies(scintilla build_scintilla)
add_executable(foo foo.c)
target_link_libraries(foo scintilla)
# note, this will only work on linux/unix platforms, also it does building
# in the source tree which is also sort of bad style and keeps out of source
# builds from working.
OK, I think I have it somewhat; basically, in the CMakeLists.txt that build scintilla, I used this only:
ADD_CUSTOM_TARGET(
scintilla.a ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... and then, the slightly more complicated part, was to find the correct cmake file elsewhere in the project, where the ${PROJECT_NAME} was defined - so as to add a dependency:
ADD_DEPENDENCIES(${PROJECT_NAME} scintilla.a)
... and finally, the library needs to be linked.
Note that in the commands heretofore, the scintilla.a is merely a name/label/identifier/string (so it could be anything else, like scintilla--a or something); but for linking - the full path to the actual `scintilla.a file is needed (which in this project ends up in a variable ${SCINTILLA_LIBRARY}). In this project, the linking basically occurs through a form of a
list(APPEND PROJ_LIBRARIES ${SCINTILLA_LIBRARY} )
... and I don't really know how cmake handles the actual linking afterwards (but it seems to work)
For consistency, I tried to use ${SCINTILLA_LIBRARY} instead of scintilla.a as identifier in the ADD_CUSTOM_TARGET, but got error: "Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate files". So probably this could be solved smarter/more correct with ADD_CUSTOM_COMMAND - however, I read that it "defines a new command that can be executed during the build process. The outputs named should be listed as source files in the target for which they are to be generated."... And by now I'm totally confused so as to what is a file, what is a label, and what is a target - so I think I'll leave at this (and not fix it if it ain't broken :) )
Well, it'd still be nice to know a more correct way to do this eventually,
Cheers!