CMAKE Required header sys/stat.h not found - c++

I am trying to configure the bcl2fastq program that uses CMake. I found the line that triggers this error message
file:bcl2fastq/src/cmake/cxxConfigure.cmake
############## content ####################
..... # ignoring many lines
bcl2fastq_find_header_or_die(HAVE_SYS_STAT_H sys/stat.h)
......# more lines following
error message:
-- time.h found as /usr/include/time.h
-- unistd.h found as /usr/include/unistd.h
CMake Error at cmake/macros.cmake:80 (message):
Required header sys/stat.h not found.
Call Stack (most recent call first):
cmake/cxxConfigure.cmake:41 (bcl2fastq_find_header_or_die)
cxx/CMakeLists.txt:34 (include)
On my system, the sys/stat.h is located in
/usr/include/x86_64-linux-gnu
In the past, I add a symbolic link in /usr/include to the sys/stat.h, which patched the problem. Can someone suggest a better method by modifying the CMake files?
Digging deeper, I found the macros.cmake file in the same directory as cxxConfigure.cmake contains the macro definition:
#
# Macro to find libraries, with support for static-only search
#
macro(bcl2fastq_find_header_or_die variable file)
find_file(${variable} ${file} HINTS ENV C_INCLUDE_PATH ENV CPATH ENV CPLUS_INCLUDE_PATH)
if (${variable})
message(STATUS "${file} found as ${${variable}}")
else (${variable})
message(FATAL_ERROR "Required header ${file} not found.")
endif (${variable})
endmacro(bcl2fastq_find_header_or_die)
Then I did the following:
export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
After that, CMake seems to be happy. Not sure this is the proper way to handle this problem.

Exporting the environment variable like
export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
is one use.
Moreover, according to the doc on the find_path command, PATHS should be used over HINTS for hard-coded guesses, which means modifying macros.cmake like this
find_file([...] PATHS /usr/include/x86_64-linux-gnu)
is more appropriate. For more flexibility, this could be combined with a PATHS ENV variable, too. The use of PATHS vs HINTS has also been asked in the CMake mailing list here, but the explanation didn't offer much more than the documentation entry.

I created a folder called sys in /usr/include.
Copied over the stat.h into that folder and ran the make command again. The bcl2fastq build completed without any issues.

Write <sys/stat.h> instead of <stat.h> in your code.

Related

Why does CMake Fail to Link Libbitcoin C++?

I have recently installed CMake in order to write code to make use of Libbitcoin in C++ but I am having a hard time, I was trying to build the example code on GitHub here. And it haters been going terribly. I can't manage to link the library right in CMake, here is my code. I read and people were saying that I should try Autoconf but I have no idea how to even start that as I know nothing about Autoconf. I have CMake 3.16, and installed Libbitcoin with brew but alias were made in /usr/local/include for the library, I am on Mac OS X 10.15. The CMake runs fine but when running "make", it responds with:
Scanning dependencies of target CreateAddr
main.cxx:1:10: fatal error: bitcoin/bitcoin.hpp: No such file or directory
1 | #include <bitcoin/bitcoin.hpp>
| ^~~~~~~~~~~~~~~~~~~~~
Here is my CMake text:
Please all help is appreciated I am beyond lost.
It is hard to be sure without knowing the specifics of your installation, but it appears that your include directory paths may be overlapping with what is specified for the header in main.cxx. The include_directories() call tells the compiler to include headers from this directory:
/usr/local/include/bitcoin
Then, in main.cxx, you're including the file with bitcoin/bitcoin.hpp. Combining these suggests the file is located here:
/usr/local/include/bitcoin/bitcoin/bitcoin.hpp
The error states the header could not be found, so perhaps you meant to locate it here:
/usr/local/include/bitcoin/bitcoin.hpp
In that case, just remove the relative directory path from the main.cxx file, like this:
#include <bitcoin.hpp>
Also, you want to link to your libbitcoin library correctly. Using link_directories() is not recommended. Instead, you can specify the full path to your libbitcoin library directly in the call to target_link_libraries(). The library may not be located in /usr/local/include/bitcoin. With these changes, the last few lines in your CMake would look something more like this:
include_directories(/usr/local/include/bitcoin)
add_executable(CreateAddr main.cxx)
target_link_libraries(CreateAddr PUBLIC /your/path/to/libs/libbitcoin.so)

How to configure DBus dependencies with CMake

I am new to CMake and DBus. I am following along the guide here and make a basic program compile and execute.
The first problem that I ran into was my program will not find
<dbus/dbus.h>
I got around that issue by adding some include directories to my CMakeList.txt.
Currently, my CMakeLists.txt looks like this:
...
include_directories(/usr/lib/)
include_directories(/usr/include/dbus-1.0/)
include_directories(/usr/lib/x86_64-linux-gnu/dbus-1.0/include)
include_directories(/usr/include/glib-2.0)
include_directories(/usr/lib/x86_64-linux-gnu/glib-2.0/include/)
set (LIBS
dbus-1
dbus-glib-1
)
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${LIBS} )
Now, my program is complaining about not being able to find dbus-arch-deps.h
/usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory
#include <dbus/dbus-arch-deps.h>
I know that the solution for this is to use proper command line flags or pkg-config. As discussed here and numerous other posts.
However, I do not know how to configure CMakeLists.txt to have similar effect.
My guess would be to add something like find_package(dbus-1) to CMakeLists.txt. And if that is correct, I am going to have to write my own Finddbus-1.cmake. Does this sound correct? Or is there an easier way?
I will appreciate any pointers.
You may get an existing FindDBus.cmake script (e.g., this one), copy it into your project, and use as
find_package(DBus REQUIRED)
# Use results of find_package() call.
include_directories(${DBUS_INCLUDE_DIRS})
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${DBUS_LIBRARIES})
Alternatively, as you know pkgconfig can find DBus, you may use CMake module PkgConfig. Actually, FindDBus.cmake script, referenced above, uses PkgConfig module in its implementation. Possible usage could be:
find_package(PkgConfig REQUIRED) # Include functions provided by PkgConfig module.
pkg_check_modules(DBUS REQUIRED dbus-1) # This calls pkgconfig with appropriate arguments
# Use results of pkg_check_modules() call.
include_directories(${DBUS_INCLUDE_DIRS})
link_directories(${DBUS_LIBRARY_DIRS})
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${DBUS_LIBRARIES})
However, using link_directories is not recommended, it is better to use absolute paths to libraries in target_link_libraries() call. That is why it is better to combine pkg_check_modules with find_library, as it is done in the referenced Find script. That answer describes generic way for use result of pkgconfig in CMake.

Using GPGME in Debian for C++ Application

I would like to use GPGME for key generation and encryption in my C++ application. However, while trying to get started, I got stuck with a problems:
I dowloaded the dev package for my debian system. Now I would like to tell my compiler (gcc in Qt Creator) where to find the library with cmake using the tool mentioned in the documentation. But I don't know how to add gpgme-config --cflags --libs to my compiler flags. This didn't work:
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} `gpgme-config --cflags --libs` ")
When I try to build the app the compiler can't find gpgme-config:
c++: error: $(gpgme-config: File or Directory not found
c++: error: unrecognized command line option ‘--cflags’
c++: error: unrecognized command line option ‘--libs)’
Anyway executing gpgme-config --cflags --libs on command line DOES give me a result:
-L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lgpg-error
I know the documentation also mentions Automake and libtool to make this process easier. But I neither used Automake or libtool before.
UPDATE:
I also tried to use a FindGpgme.cmake file for GPGME. But the first file I used required several other cmake files, which I also downloaded. I put them in the same directory as FindGpgme.cmake. The main cmake file (FindGpgme.cmake) was found, but MacroEnsureVersion and MacroBoolTo01 not. My change to my CMakeLists.txt was the following:
include(cmake_modules/FindGpgme.cmake)
find_package(Gpgme)
I tried relative and absolute path to the other files in FindGpgme.cmake. Same problem - cmake can't find them. My second try was with the file I found on gitweb. The error was:
CMake Error at cmake_modules/FindGpgme.cmake:376 (set_package_properties):
Unknown CMake command "set_package_properties".
Call Stack (most recent call first):
CMakeLists.txt:7 (include)
I have absolutely no glue how to fix that set_package_properties problem.
UPDATE 2
I added
include(FeatureSummary)
to my CMakeLists.txt as proposed by kfunk. Now I get the following error:
CMake Warning at CMakeLists.txt:9 (find_package): By not providing
"FindGpgme.cmake" in CMAKE_MODULE_PATH this project has asked CMake
to find a package configuration file provided by "Gpgme", but CMake
did not find one.
Could not find a package configuration file provided by "Gpgme" with
any of the following names:
GpgmeConfig.cmake
gpgme-config.cmake
Add the installation prefix of "Gpgme" to CMAKE_PREFIX_PATH or set
"Gpgme_DIR" to a directory containing one of the above files. If
"Gpgme" provides a separate development package or SDK, be sure it
has been installed.
Even the message description seams pretty detailed I don't know how to add the FindGpgme.cmake to CMAKE_MODULE_PATH or how to add the requested prefix to CMAKE_PREFIX_PATH. The dev package however is definitely installed (using package manager)
I'd suggest to use a proper CMake find script to look up the GPGME installation:
Example here:
https://quickgit.kde.org/?p=kwallet.git&a=blob&h=7a092104ba0604b0606c4662750b8b32c5c3e2c6&f=cmake%2FFindGpgme.cmake&o=plain
Then something like this in your CMake code (untested):
find_package(Gpgme)
include_directories(${GPGME_INCLUDES})
target_link_libraries(YOURTARGET ${GPGME_VANILLA_LIBRARIES)

Adding LLVM to my Cmake Project: Why are there hardcoded paths in LLVM's Cmake file?

I'm using LLVM/Clang in my C++ project. I can build and run everything fine with a Makefile.
I'm now trying to move to Cmake and I can't get things to work. Let me explain what I've done.
I'm following this tutorial:
http://llvm.org/docs/CMake.html#embedding
A relevant snippet from that webpage is:
From LLVM 3.5 onwards both the CMake and autoconf/Makefile build
systems export LLVM libraries as importable CMake targets.
Great! I'll go download LLVM 3.5 and I should be good to go. I went to the download page:
http://llvm.org/releases/download.html
and downloaded the pre-built binaries for Clang for Ubuntu 14.04 Linux.
Then, I added the following to my CMakeLists.txt file:
find_path (LLVM_DIR LLVM-Config.cmake
/home/dev/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu/share/llvm/cmake
)
message(STATUS "LLVM_DIR = ${LLVM_DIR}")
find_package(LLVM REQUIRED CONFIG)
(This is the same as the tutorial, except I set LLVM_DIR since it is currently in a non-standard location.)
When I run cmake, I get the following error:
[dev#beauty:/path/to/project/build (develop)] $ cmake ..
-- LLVM_DIR = /home/dev/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu/share/llvm/cmake
CMake Error at /home/dev/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu/share/llvm/cmake/LLVMConfig.cmake:50 (include):
include could not find load file:
/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/share/llvm/cmake/LLVMExports.cmake
Call Stack (most recent call first):
CMakeLists.txt:14 (find_package)
CMake Error at /home/dev/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu/share/llvm/cmake/LLVMConfig.cmake:53 (include):
include could not find load file:
/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/share/llvm/cmake/LLVM-Config.cmake
Call Stack (most recent call first):
CMakeLists.txt:14 (find_package)
So Cmake seems to be finding LLVM's Cmake file, but Cmake is complaining about some path starting with /home/ben/.
Indeed, it appears that LLVM's LLVMConfig.cmake file has some absolute paths in it that are not relevant for my machine. For example:
[dev#beauty:~/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu ] $ head ./share/llvm/cmake/LLVMConfig.cmake
# This file provides information and services to the final user.
set(LLVM_INSTALL_PREFIX "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install")
set(LLVM_VERSION_MAJOR 3)
set(LLVM_VERSION_MINOR 5)
set(LLVM_VERSION_PATCH 0)
set(LLVM_PACKAGE_VERSION 3.5.0)
set(LLVM_COMMON_DEPENDS )
Who's ben and what's he doing in this file? He shows up in a few more places:
[dev#beauty:~/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu ] $ grep ben ./share/llvm/cmake/LLVMConfig.cmake
set(LLVM_INSTALL_PREFIX "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install")
set(LLVM_INCLUDE_DIRS "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/include")
set(LLVM_LIBRARY_DIRS "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/lib")
set(LLVM_CMAKE_DIR "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/share/llvm/cmake")
set(LLVM_TOOLS_BINARY_DIR "/home/ben/development/llvm/3.5/final/Phase3/Release/llvmCore-3.5.0-final.install/bin")
Needless to say, those paths do not exist on my machine. I'm confused as to why these files have these paths in them? Am I supposed to run a tool or something to change these paths for my machine? Or do I need to change them all manually?
EDIT: Out of curiosity, I manually changed all those paths to point to paths on my machine:
[dev#beauty:~/Downloads/clang+llvm-3.5.0-x86_64-linux-gnu/share/llvm/cmake ] $ sed -i -e's/.home.ben.development.llvm.3.5.final.Phase3.Release.llvmCore-3.5.0-final.install/\/home\/dev\/Downloads\/clang+llvm-3.5.0-x86_64-linux-gnu/g' *
After that, Cmake no longer complained and my build proceeded.
I'd still like to know why I needed to do that.
Sounds like a LLVM bug. Feel free to enter it: http://llvm.org/bugs
We just have to build with 'Ninja' instead of 'Unix Makefiles' and that's all

CMake FIND_PACKAGE succeeds but returns wrong path

I'm trying to have CMake 2.8.6 link to boost::program_options using the following code in my CMakeLists.txt
FIND_PACKAGE(Boost COMPONENTS program_options REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIR})
ADD_EXECUTABLE (segment segment.cpp)
TARGET_LINK_LIBRARIES (segment ${Boost_LIBRARIES})
The find command seems to succeed but passes the wrong directory to the linker. The package is actually in:
`/usr/lib64/libboost_program_options-mt.so.5`
but CMakeFiles/segment.dir/link.txt lists the following:
/cm/shared/apps/gcc/4.4.6/bin/c++ CMakeFiles/segment.dir/segment.cpp.o -o segment -rdynamic /usr/lib64/lib64/libboost_program_options-mt.so.5 -lpthread -lrt -Wl,-rpath,/usr/lib64/lib64
Note the extra lib64 in the path. Also, the -l flag in front of the path seems to be missing.
When running CMake it reports that it correctly finds the package, and the {$Boost_LIBRARIES} variable seems to list the correct libs:
Boost found.
Found Boost components:
program_options
${Boost_LIBRARIES} - optimized;boost_program_options-mt-shared;debug;boost_program_options-mt-shared-debug
The generated CMakeCache.txt file starts with:
//The directory containing a CMake configuration file for Boost.
Boost_DIR:PATH=/usr/lib64/boost
//Boost include directory
Boost_INCLUDE_DIR:FILEPATH=/usr/include
Which seems to be correct. But when running make it uses the path in link.txt above and I get the error:
make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_program_options-mt.so.5', needed by `segment'. Stop.
make[1]: *** [CMakeFiles/segment.dir/all] Error 2
make: *** [all] Error 2
What might cause this extra injection of a subdir into the path? What might cause link.txt to be generated in this way? And how do I fix it (or work around it)?
This problem occurs when using some older versions of boost with cmake-2.8.6-rc2 or later, where the boost package finding code was changed.
The problem can be worked around by specifying -DBoost_NO_BOOST_CMAKE=ON on the cmake command line.
The actual commit where this problem is introduced is 7da796d1fdd7cca07df733d010cd343f6f8787a9, and can be viewed here.
The problem is with the boost-devel distributed file: /usr/lib64/boost/Boost-relwithdebinfo.cmake
The cmake-2.6 package does not use this file at all, because the FindBoost.cmake file returns (correct) full-paths to boost libraries. The cmake28-2.8.8 FindBoost.cmake file returns library strings like "boost_date_time-mt-shared", which are targets defined in /usr/lib64/boost/Boost-relwithdebinfo.cmake.
At the very top of /usr/lib64/boost/Boost-relwithdebinfo.cmake, a variable named _IMPORT_PREFIX is defined from the location of the cmake file itself, and then used like so:
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RelWithDebInfo".
#----------------------------------------------------------------
# Commands may need to know the format version.
SET(CMAKE_IMPORT_FILE_VERSION 1)
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
# Import target "boost_date_time-static" for configuration "RelWithDebInfo"
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES
IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a"
)
This sets _IMPORT_PREFIX to "/usr/lib64", which is concatenated with another string that has /lib64/ in it as well. I found that if I simply change the file to include a 3rd GET_FILENAME_COMPONENT call, it works fine. Like so:
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RelWithDebInfo".
#----------------------------------------------------------------
# Commands may need to know the format version.
SET(CMAKE_IMPORT_FILE_VERSION 1)
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
# Import target "boost_date_time-static" for configuration "RelWithDebInfo"
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES
IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a"
)
This seems to be an issue with CMake 2.8.6 on CentOS. When doing the same with 2.6.4 or 2.8.3 it works correctly. Also with 2.8.7 on OS X it also works correctly.
I also see the problem on the pre-compiled cmake version 2.8.8 using CentOS 64-bit 6.2
I noticed this issue on cmake version 2.8.11.2 with boost-1.41.0-18.el6.x86_64
The approved answer does not seem satisfactory because appending this define to the cmake runtime I get:
CMake Warning:
Manually-specified variables were not used by the project:
Boost_NO_BOOST_CMAKE
I can't seem to comment or downvote due to not participating in stackoverflow enough. That is a chicken and egg problem!
I also can't seem to upvote the explanation by Kai Meyer. However, I think this really explains the problem.
From what I am gathering it seems that in summary, FindBoost.cmake provided by CMake seems to all of a sudden fail to find Boost, so the find code is now searching via the boost provided script for cmake, which in turn has a bug and seems to not return the correct path.
while building package from AUR following prefix helped to find Boost:
BOOST_ROOT=/usr
example:
BOOST_ROOT=/usr makepkg -si