I would like to use CMake to build my own libraries executables. I have installed both dynamic and static x64 versions of 3rd party libraries like boost. When I compile my own projects with cmake I can't get it to use the static versions. Here is my setup:
cmake 3.18.1
vcpkg pulled from master branch (Aug 11, 2020)
Visual Studio 2019 16.6.1.0
Running in a docker container with Windows Server Core 2019
When I just do cmake .. and cmake --build . it defaults to x64-windows as expected. I have one 3rd party library that only exist as a static library (x64-windows-static) so then I try this:
cmake .. "-DVCPKG_TARGET_TRIPLET=x64-windows-static" "-DCMAKE_TOOLCHAIN_FILE=C:/Tools/vcpkg/scripts/buildsystems/vcpkg.cmake"
according to other posts. I have done different experiments and versions of these commands and the result is either:
vcpkg is not enabled
using x64-windows
But never "using x64-windows-static" which is what I want. I just can't make this to work. I have tried to set environment variables or adding the commands to the cmake files as well. But the result is the same, it refuses to use the "x64-windows-static" triplet. All third party libraries that I have used, have been compiled and installed properly with both versions.
Any ideas what I do wrong?
Related
I'm trying to get a native Windows build working in which we depend on librsvg-2. It's correctly installed through vcpkg. We usually build with cmake and have made a custom module to find this library. This works great in the unix world, but not within Windows and targeting either a Debug build or a Release build (from visual studio). This is due to the fact the actual lib file gets suffixed with a d on Windows.
This is our FindLibRSVG.cmake
include(LibFindMacros)
libfind_package(LibRSVG Cairo)
libfind_package(LibRSVG GDK-PixBuf)
libfind_pkg_detect(LibRSVG librsvg-2.0
FIND_PATH librsvg/rsvg.h PATH_SUFFIXES librsvg-2 librsvg-2.0
FIND_LIBRARY rsvg-2
)
libfind_process(LibRSVG)
To get the build working on Windows i have to specify a flag to our cmake command like this:
cmake .. -DLibRSVG_LIBRARY=./vcpkg_installed/x64-windows/debug/lib/rsvg-2.40d.lib
Do note the d at the end of the library.
I know there is a cmake module SelectLibraryConfigurations available but i'm not quite sure how to use this properly.
What i'd like to achieve is to be able to build in debug mode without having to provide this flag.
Note: The LibFindMacros implementation can be found here
The Poco Libraries can be really powerful and useful... but also stubbornly hard to build :-( I am now several days into a process of trying to upgrade from:
Poco 1.9.0, win32 build, including NetSSL_OpenSSL and Data/MySQL, on Windows 7, using MS Visual Studio 2015 successfully built via buildwin.cmd script from Windows Explorer since April 2018
to:
Poco 1.10.1, win32 and x64 builds, including NetSSL_OpenSSL and Data/MySQL (32-bit) or Data/PostgreSQL (64-bit), on Windows 10, using MS Visual Studio 2019, built via any means at all.
So far I cannot make the build process budge in any significant direction from my old build to my new target via any means... except possibly via CMake.
Since CMake appears to be the preferred way to build Poco, and nothing else (e.g. buildwin.cmd) works as expected, I am trying to rebuild the 32-bit DLLs so I can test with older proven components in my application. It looks promising. But the crypto build complains:
LINK : fatal error LNK1104: cannot open file 'libcrypto.lib' [S:\3rdparty\Poco-build32\Crypto\Crypto.vcxproj]
That's strange: in the entire Crypto.vcxproj file, there is no mention of libcrypto.lib at all, only libcrypto32MD.lib and libcrypto32MDd.lib. Why is it even looking for libcrypto.lib? Even so, if it is supposed to be finding libcrypto.lib, why doesn't it succeed when it is freshly installed in C:\Program Files (x86)\OpenSSL-Win32\lib and OPENSSL_ROOT_DIR is set to C:\Program Files (x86)\OpenSSL-Win32? What am I missing? I got to this point via:
cmake -HS:\3rdparty\Poco -B S:\3rdparty\Poco-build32 -G "Visual Studio 16 2019" -A win32
cmake --build s:\3rdparty\Poco-build32 --config RelWithDebInfo
UPDATE: in case I modified anything while trying to make it build in other ways (buildwin.cmd, Batch Build in Visual Studio), I set the entire Poco file structure aside, and unzipped a fresh copy. The OpenSSL install is also fresh and untouched. The x64 build produces the identical error...
There is a hidden readme file https://github.com/pocoproject/poco/blob/master/README. I'm quoting:
Through the Poco/Crypto/Crypto.h and Poco/Net/NetSSL.h header files,
Visual C++ will automatically link the libcrypto.lib and libssl.lib
libraries. If your OpenSSL libraries are named differently, compile
with the macro POCO_EXTERNAL_OPENSSL defined and edit the project
files accordingly.
You can try to re-compile with the POCO_EXTERNAL_OPENSSL macro set accordingly (see Foundation/include/Poco/Config.h). (source)
Or what I did. Edit the file Crypto/include/Poco/Crypto/Crypto.h, remove all if-else logic around pragmas and leave only libraries that use have:
#pragma comment(lib, "libcrypto64md.lib")
#pragma comment(lib, "libssl64md.lib")
This is not a direct answer - it is an alternative build path that has been confirmed to produce viable DLLs. Try:
Start command line tool from Visual Studio
Invoke vcvars32.bat or vcvars64.bat to ensure environment is correct for Win32 or x64 build.
I found these scripts in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build
Ensure the Poco buildwin.cmd script is configured to specify location of OpenSSL include and lib sub-folders
you will likely have to modify the script between builds if building both 32- and 64-bit builds since openSSL-Win32 and openSSL-Win64 are separate installations
specify include and lib paths for other components the same way (e.g. MySQL and/or PostgreSQL, etc)
Edit the Poco "components" file to eliminate any components not required that will stop build
Invoke buildwin, e.g.:
buildwin 160 shared both Win32 samples notests
buildwin 160 shared both x64 samples notests
My cmake --version is 2.8.12.2.
I configure my project build with these commands:
cmake ../klein/ -DBUILD_KLEIN_DEPS=1 -DCMAKE_EXPORT_COMPILE_COMMANDS=1
cmake ../klein/ -DBUILD_KLEIN_DEPS=1 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
cmake ../klein/ -DBUILD_KLEIN_DEPS=1 -DCMAKE_EXPORT_COMPILE_COMMANDS=on
CMAKE_EXPORT_COMPILE_COMMANDS=1 cmake ../klein/ -DBUILD_KLEIN_DEPS=1
From a clean build, and from a directory with an existing successful build. And want to see the compiler_commands.json file, but it does not appear.
At which moment should it be created: after cmake, or after make command? Where should it be in ./, or in ../klein directory? My cmake does not say anything about this option while it always complains about unused build variables.
Should it work from in a "dirty" directory, where I've performed one successful build, or does it work only on a fresh run in an empty folder?
Edit:
I use a default generator "Unix Makefiles" on my ubuntu linux machine
Edit2:
I'm not an author of the project under the question (I just want to explore it with rtags which requires compile_commands.json file), and I'm not very familiar with CMake mechanics. However, the CMakeLists.txt is probably configured as a super-build (it indeed downloads and builds dependencies - like llvm, z3, ...), and it includes ExternalProject, however it also builds the project itself (klein) from sources. So it's a mix, as I would say.
Can you specify what generator your using? A quick scan of the cmake source from version 3.1.0 suggests that this command is still only available in the following 2 cases.
if(CMAKE_GENERATOR MATCHES "Unix Makefiles")
and
if(CMAKE_GENERATOR MATCHES "Ninja")
if you're using Visual Studio directly you're out of luck unless you want to add a patch to CMake. Otherwise, I know many Windows developers who've gone to Ninja. One advantage is that it's vastly faster than Visual Studio for building. If you are, in fact using Ninja or Unix Makefiles, then it's worth digging deeper.
I need to give the path to the local build of a library (in my case :Eigen) to build PCL library locally on my lab machine.
I do not have root privileges and cant do 'sudo make install'. so i need to build the PCL library locally on my lab machine. PCL has dependent libraries like Eigen and Flann... how can I give the path of these local builds while building PCL locally?
I was able to build Eigen locally on the machine as:
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/home/localEigen
i need to give the path of this local build in the cmake for PCL.
I tried this but it fails to find Eigen:
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/home/i7264040/localPCL/ -DCMAKE_INSTALL_INCLUDEDIR:PATH=/home/i7264040/localEigen/include/
Need help badly...
Thanks
This has two parts:
For the Eigen library, define CMAKE_INSTALL_PREFIX to somewhere where you can install it without needing privilegies. Build and install Eigen.
For the dependent library:
if it has some setting for where to look for Eigen, set it to the install prefix of Eigen (often environment variable; unfortunately cmake does not have any standard for providing library-specific paths), otherwise
set CMAKE_PREFIX_PATH to the value of install prefix given to Eigen.
In short I'm trying to cross compile CMake with CMake, and I don't think I'm linking libraries correctly. What I want to do may not be possible, but I'd at least like to know why it isn't possible if that's the case.
System: The host is a Linux box with a Cavium ARM9 CPU. It's currently running version 2.6.24.4 of the Linux kernel and Debian 5.0 (Lenny). My workstation is a Core i5 running Ubuntu 12.04 LTS (Precise Pangolin).
My overall goal is to get ROS running on the Linux box. I have to compile from source rather than use apt since Debian 6.0 (Squeeze) binaries require thumb support that the Cavium does not give, and not many of the needed packages are available for Debian 5.0 (Lenny). I'd made progress installing the various libraries needed, but when I got to step 1.3.1 and tried to run CMake, I got the error
CMake 2.8 or higher is required. You are running version 2.6.0
Next I tried to download and build CMake 2.8.8 on the Linux box itself, but it was too much for the system. When that failed, I downloaded the toolchain suggested on the manufacturer's website and used the cross-compiling guide at [www.cmake.org/Wiki/CMake_Cross_Compiling] to build the CMake executables. Here is my toolchain file:
# This one is important
SET(CMAKE_SYSTEM_NAME Linux)
# Specify the cross compiler
SET(CMAKE_C_COMPILER /pathto/crosstool-linux-gcc-4.5.2-gclibc-2.9-oabi/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc)
SET(CMAKE_CXX_COMPILER /pathto/crosstool-linux-gcc-4.5.2-gclibc-2.9-oabi/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-g++)
# Where is the target environment
SET(CMAKE_FIND_ROOT_PATH /pathto/crosstool-linux-gcc-4.5.2-gclibc-2.9-oabi/arm-unknown-linux-gnu /pathto/crosstool-linux-gcc-4.5.2-gclibc-2.9-oabi/arm-unknown-linux-gnu/arm-unknown-linux-gnu)
# Search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# For libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
However, use of the binary on the Linux box gives the error
cmake: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by cmake)
Sure enough, the library is not there:
prompt# strings /usr/lib/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBC_2.3
GLIBC_2.0
GLIBC_2.3.2
GLIBC_2.1
GLIBC_2.1.3
GLIBC_2.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
I've never cross-compiled before, but I can see one of two scenarios happening: either the binary got created with a link to a higher version of glibcxx on the host machine or the manufacturer's toolchain is more modern than their image. I don't know how to check which is happening or if something else is happening that I don't know about.
My last effort involved trying to statically cross-compile CMake to hopefully get rid of the linking error with
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain-technologic.cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXE_LINKER_FLAGS_RELEASE="-static" ..
I got build errors, and that binary didn't work either. I got:
FATAL: kernel too old
Segmentation fault
I'd try installing glibcxx 3.4.14 on the Linux box, but it doesn't look like it's available for this processor.
I've tried searching for CMake dependencies or system requirements and can't find anything. I've also searched on how to build CMake, but most searches turn up how to build other things with CMake rather than building CMake itself.
I do cross-compile a lot for ARM9 devices using CMake, and indeed this looks like you're not linking to the same libs you have on your target device. You shouldn't need to build CMake yourself to get this done, since it does have good support for cross-compiling since version 2.6. Just make sure you set the CMAKE_FIND_ROOT_PATH variable to a path where you have an exact copy of the root filesystem you have on your target device (with libraries and binaries pre-compiled for the target processor). That should solve your problems.
As a sidenote, I like to use crosstool-ng for building my cross-compilers. It is a really nice tool which helps you to build them from scratch, so I try to match the compiler version and glibc to the ones originally used to build the root filesystem (I usually start with a ready made root filesystem from ARMedslack, since I use Slackware for my development box and ARMedslack for my ARM targets).