Trying to compile dot11decrypt on debian, installed apt-get install libtins4.0 and apt-get install libtins-dev, but cmake .. can't find package libtins, heres the error:
CMake Error at CMakeLists.txt:4 (FIND_PACKAGE):
By not providing "Findlibtins.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "libtins", but
CMake did not find one.
Could not find a package configuration file provided by "libtins" with any
of the following names:
libtinsConfig.cmake
libtins-config.cmake
Add the installation prefix of "libtins" to CMAKE_PREFIX_PATH or set
"libtins_DIR" to a directory containing one of the above files. If
"libtins" provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also "/home/user/dot11decrypt/build/CMakeFiles/CMakeOutput.log".
cat:dot11decrypt/CMakeLists.txt
1. CMAKE_MINIMUM_REQUIRED(VERSION 2.8.1)
2. PROJECT(dot11decrypt)
3.
4. FIND_PACKAGE(libtins REQUIRED)
5.
6. SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
7.
8. ADD_EXECUTABLE(dot11decrypt dot11decrypt.cpp)
9. TARGET_LINK_LIBRARIES(dot11decrypt ${LIBTINS_LIBRARIES} pthread)
find / -name Findlibtins.cmake or libtinsConfig.cmake brings no result.
I found those files on internet but still no success, i think i have to install something but don't know what.
I went with Tsyvarev solution.
# installing missing dependencies for libtins
apt-get install libpcap-dev libssl-dev cmake
# installing libtins
git clone https://github.com/mfontanini/libtins.git
cd libtins
mkdir build
cd build
cmake ../
make
checkinstall
Now cmake will reach dot11decrypt missing files.
# installing dot11decrypt
git clone https://github.com/mfontanini/dot11decrypt.git
cd dot11decrypt/
mkdir build
cd build/
cmake ../
make
Now you should have dot11decrypt executable.
If i would have to do it again i would try Alex Reinking solution first.
You don't need to compile from source... find_package is a very flexible configuration point! You'll just need to provide your own find module that is sufficient for the build. Fortunately, this is very simple. Here's what I did:
$ https://github.com/mfontanini/dot11decrypt
$ cd dot11decrypt
$ mkdir _patches
$ vim _patches/Findlibtins.cmake
$ cat _patches/Findlibtins.cmake
find_package(PkgConfig REQUIRED)
pkg_check_modules(LIBTINS REQUIRED libtins)
$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_MODULE_PATH=$PWD/_patches
CMake Deprecation Warning at CMakeLists.txt:1 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'libtins'
-- Found libtins, version 4.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/dot11decrypt/build
$ cmake --build build/
[ 50%] Building CXX object CMakeFiles/dot11decrypt.dir/dot11decrypt.cpp.o
/home/alex/test/dot11decrypt/dot11decrypt.cpp: In function ‘void decrypt_traffic(unique_fd, const string&, decrypter_tuple)’:
/home/alex/test/dot11decrypt/dot11decrypt.cpp:333:39: warning: ‘Tins::Sniffer::Sniffer(const string&, unsigned int, bool, const string&, bool)’ is deprecated [-Wdeprecated-declarations]
333 | Sniffer sniffer(iface, 2500, false);
| ^
In file included from /usr/include/tins/dns.h:38,
from /usr/include/tins/tins.h:33,
from /home/alex/test/dot11decrypt/dot11decrypt.cpp:25:
/usr/include/tins/sniffer.h:369:5: note: declared here
369 | TINS_DEPRECATED(Sniffer(const std::string& device, unsigned max_packet_size,
| ^~~~~~~~~~~~~~~
[100%] Linking CXX executable dot11decrypt
[100%] Built target dot11decrypt
The key here is to create a minimal Find module. This is just two lines on my system since it isn't meant to be reusable...
# _patches/Findlibtins.cmake
find_package(PkgConfig REQUIRED)
pkg_check_modules(LIBTINS REQUIRED libtins)
This just delegates the responsibility of setting the LIBTINS_LIBRARIES to pkg-config. To connect this find module to the build, I just set -DCMAKE_MODULE_PATH=$PWD/_patches at the CMake configure command line.
Also, you should definitely open a bug report with the dot11decrypt author about their broken and outdated build. Notice the strongly worded deprecation warning in the logs I posted.
Related
I'm trying to compile a cpp code which uses libavcodec:
#include <libavcodec/avcodec.h>
I tried all variations of
find_package()
with names like ffmpeg for which I get
CMake Warning at CMakeLists.txt:17 (find_package):
By not providing "Findffmpeg.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "ffmpeg", but
CMake did not find one.
Could not find a package configuration file provided by "ffmpeg" with any
of the following names:
ffmpegConfig.cmake
ffmpeg-config.cmake
Add the installation prefix of "ffmpeg" to CMAKE_PREFIX_PATH or set
"ffmpeg_DIR" to a directory containing one of the above files. If "ffmpeg"
provides a separate development package or SDK, be sure it has been
installed.
By the way, I did sudo apt install -y ffmpeg before all that.
I'm compiling with
add_executable(my_executable ${sources})
Minimal working example
CMakeLists.txt
cmake_minimum_required(VERSION 3.1.0)
project(hello)
find_library(AVCODEC_LIBRARY avcodec)
add_executable(hello main.cpp)
target_link_libraries( hello PRIVATE ${AVCODEC_LIBRARY})
main.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, World!";
return 0;
}
Output:
lz#vm:~/mcve$ cmake .
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
AVCODEC_LIBRARY
linked by target "hello" in directory /home/lz/mcve
-- Configuring incomplete, errors occurred!
See also "/home/lz/mcve/CMakeFiles/CMakeOutput.log".
This is what was missing (even though libavcodec appeared in some folders of my system)
sudo apt install -y libavcodec-dev libavformat-dev libavdevice-dev libavfilter-dev
I'm using cmake to compile a C++ project, and I want cmake to generate all the output files(metafiles like Makefile used to create binaries) in the build folder. I've checked all the answers in How do I make cmake output into a 'bin' dir?, none of them worked for me(suprisingly!). Files are generated in the root folder instead of in the build folder, what's wrong here? I guess I must have missed something.
Code Structure
➜ cmake-test tree .
.
├── CMakeLists.txt
└── hello.cpp
0 directories, 2 files
CMakeLists.txt
# Specify the minimum version for CMake
cmake_minimum_required(VERSION 3.11)
# Project's name
project(hello)
# Set the output folder where your program will be created
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/build)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/build)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
# The following folder will be included
include_directories("${PROJECT_SOURCE_DIR}")
add_executable(hello ${PROJECT_SOURCE_DIR}/hello.cpp)
Build Commands and Outputs
➜ cmake-test cmake .
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/searene/CLionProjects/cmake-test
➜ cmake-test ls
bin CMakeCache.txt CMakeFiles cmake_install.cmake CMakeLists.txt hello.cpp Makefile
cmake version
➜ cmake-test cmake --version
cmake version 3.11.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
OS
Linux
The usual way to do this, rather than changing variables to set the path, is simply to create the output directory, change to it, and run cmake from there. So instead of cmake . you usually have cmake .. or similar.
I understand the initial impulse to say "But I expect my build system to write output somewhere else." But CMake is not usually used in the way you were initially expecting, and other people who run your CMake build won't expect what you were expecting, so it's probably best to just use the built-in, default behavior, which is to put the output wherever cmake was run.
Put another way: You are fighting against the tool. Don't do that.
Disclaimer: I recommend going with #john-zwinck's answer.
By default, cmake uses the current working directory as build directory and whatever path you provide as source directory. So the normal way of achieving your goal is
create the build directory (mkdir build)
go there (cd build)
call cmake with the source dir as argument (cmake path/to/source)
BUT there is another way, as far as I know not documented in the cmake docs and only kept for compatibility reasons or internal usage, that some people are using. The -B and -H flags
cmake -Hpath/to/source -Bpath/to/build
or even from the source dir
cmake . -Bbuild
Important: no space after -B.
CMake 3.19.1 (not sure how about older ones) has following option (from docs):
cmake [<options>] -S <path-to-source> -B <path-to-build>
Uses as the build tree and as the
source tree. The specified paths may be absolute or relative to the
current working directory. The source tree must contain a
CMakeLists.txt file. The build tree will be created automatically if
it does not already exist. For example:
cmake -S src -B build
I'm a beginner with opencv library. I've installed it on Ubuntu 17.04 and everything during the installation was perfect, no error at all. I've installed the Opencv-master, builded it, then I downloaded the opencv_contrib-master and everything was perfect..
I'm trying to build the scene_reconstruction using SFM (structure for motion). I've installed all the dependencies with:
sudo apt-get install libeigen3-dev libgflags-dev libgoogle-glog-dev
Then I've installed the Ceres Solver:
git clone https://ceres-solver.googlesource.com/ceres-solver
cd ceres-solver
mkdir build && cd build
cmake ..
make -j4
make test
sudo make install
Everything was ok, no error at all. I tried to write the example_sfm_scene_reconstruction.cpp following the official documentation from here (Scene Reconstruction) named it Reconstruct.cpp.
I wrote the CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6 FATAL_ERROR)
project( Reconstruct )
include_directories( /usr/local/include/eigen3 )
find_package( OpenCV REQUIRED )
find_package( Eigen3 REQUIRED )
add_executable( Reconstruct Reconstruct.cpp )
target_link_libraries( Reconstruct ${OpenCV_LIBS})
I've created the build directory and opened it with mkdir build && cd build.
Then cmake ..:
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenCV: /usr/local (found version "3.3.1")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/simocolna/Scrivania/SFM/build
But when I try to do make I have this error:
error: ‘reconstruct’ was not declared in this scope
econstruct(images_paths, Rs_est, ts_est, K,
points3d_estimated,is_projective);
I tried to follow this forum issue 476 but anything helped me.
add
#define CERES_FOUND 1
before your code
I have a 64 bit Ubuntu 14.04 VM and I am trying to compile a 32 bit application that depends on openssl and I keep getting the following error:
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES) (found
version "1.0.1f")
I have created the following test case to reproduce the error.
DockerFile
FROM ubuntu:trusty
LABEL maintainer="Diarra_Bakary#test.com"
LABEL version="1.0"
RUN dpkg --add-architecture i386 && \
apt-get update && \
apt-get install -y \
git\
cmake\
curl:i386\
libcurl4-openssl-dev:i386\
libssl-dev:i386\
uuid-dev:i386
RUN apt-get install -y \
gcc-multilib\
g++-multilib
CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
find_package(OpenSSL REQUIRED)
x86_32.cmake
SET(CMAKE_SYSTEM_NAME Linux)
# which compilers to use for C and C++
set(CMAKE_C_COMPILER gcc)
set(CMAKE_C_FLAGS -m32)
set(CMAKE_CXX_COMPILER g++)
set(CMAKE_CXX_FLAGS -m32)
Run the following commands
mkdir cmake
cd cmake
cmake -DCMAKE_TOOLCHAIN_FILE=x86_32.cmake ..
Thanks in advance
I was able to fix my issue by adding the following lines to my toolchain:
# Specify Openssl Path
SET(CMAKE_LIBRARY_PATH "/usr/lib/i386-linux-gnu")
include_directories(BEFORE /usr/include/i386-linux-gnu)
Thank you #Tsyvarev for your recommendation !
CMake suggests to try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR.
Indeed, FindOpenSSL.cmake features an option OPENSSL_ROOT_DIR which can be provided to specify the location of the install directory of OpenSSL.
Could you try something like that in your CMakeList.txt:
cmake_minimum_required(VERSION 2.8)
set(OPENSSL_ROOT_DIR /usr/local/ssl)
message("OPENSSL_ROOT_DIR is " ${OPENSSL_ROOT_DIR})
find_package(OpenSSL REQUIRED)
message("OPENSSL_FOUND is " ${OPENSSL_FOUND})
message("OPENSSL_INCLUDE_DIR is " ${OPENSSL_INCLUDE_DIR})
message("OPENSSL_CRYPTO_LIBRARY is " ${OPENSSL_CRYPTO_LIBRARY})
message("OPENSSL_SSL_LIBRARY is " ${OPENSSL_SSL_LIBRARY})
message("OPENSSL_LIBRARIES is " ${OPENSSL_LIBRARIES})
message("OPENSSL_VERSION is " ${OPENSSL_VERSION})
Of course, the folder /usr/local/ssl must be tuned to specify the installation directory, where you will find folder lib and include. In folder lib, you will find the libraries libcrypto.a and libssl.a and you will find a lot of header (.h) files in include/openssl.
Edit: if the intallation is not standard, then the environment variables must be set to the correct values without calling find_package(). For example, mine are:
OPENSSL_ROOT_DIR is /usr/local/ssl
OPENSSL_FOUND is TRUE
OPENSSL_INCLUDE_DIR is /usr/local/ssl/include
OPENSSL_CRYPTO_LIBRARY is /usr/local/ssl/lib/libcrypto.a
OPENSSL_SSL_LIBRARY is /usr/local/ssl/lib/libssl.a
OPENSSL_LIBRARIES is /usr/local/ssl/lib/libssl.a/usr/local/ssl/lib/libcrypto.a
OPENSSL_VERSION is 1.0.2d
Then, target_include_directories(), link_directories() and target_link_libraries() can be used.
I have an ExternalProject dependency that gets cloned (using git) in the build process. This all works great with CMake + Make.
mkdir build && cd build;
cmake ..
make
It correctly clones and builds the library using git when I type make.
However, when I use the Ninja Generator:
mkdir build && cd build;
cmake -GNinja ..
ninja
I get the following error:
$ cmake -GNinja .. -- The C compiler identification is AppleClang 6.0.0.6000054
-- The CXX compiler identification is AppleClang 6.0.0.6000054
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.56.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Found Git: /usr/local/bin/git (found version "2.1.2")
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/carneiro/src/gamgee/build
$ ninja
ninja: error: 'contrib/htslib-prefix/src/htslib/libhts.a', needed by 'test/gamgee_test', missing and no known rule to make it
Is git downloading of external projects not supported by the cmake+ninja combo?
Turns out if you do a clean before building, it all works and ninja does download my dependencies correctly.
So the workflow looks like this:
mkdir build && cd build
cmake -G Ninja ..
ninja clean # if you don't do this, it will not download Externalproject dependencies
ninja
Must be some kind of bug in the Ninja generator, but I'm happy with this workflow for now.