I'm currently trying to build the Apache qpid messaging broker on Windows using CMake and the Boost (C++). I went through the initial steps of setting up Qpid on Windows as specified in this file. I set the variable BOOST_ROOT to "C:/< Home >/Downloads/boost_1_61_0" initially so that CMake could find the Boost Libraries (e.g. random, math, chrono, etc.) but I got this log saying that it could only find some of the libraries, but not others. I thought that maybe the filepath needed to include the directory where the Boost libraries were actually located (i.e. C:/< Home >/Downloads/boost_1_61_0/boost) but I was unable to reset the BOOST_ROOT environment variable despite deleting it and creating another one.
I was advised on this forum to delete the cache file for CMake using the GUI so I could reset the variable, but that didn't seem to work either.
Am I using the correct file path for BOOST_ROOT? If not, how should I go about changing it?
Some of the Boost libraries (e.g. chrono) need to be compiled first. If you have only downloaded Boost library from the website, you probably have not built these libraries. Check Boost website for instructions how to build on Windows. The site also lists which libraries need to be built. Alternatively, you can search for sites where pre-built Boost libraries are hosted. You can download and install from there.
Related
I'm currently switching to CMake for my build system (on Windows). I want to build both a shared and a static version of my library.
To include 3rd-party libraries (mostly from github), I run their CMake and install them. I then get a folder /lib/$LibName/cmake, which contains $LibnameConfig.cmake. This can be loaded into my own project using find_package, and is overall quite nice.
Now for the problem: Every last library I'm using overwrites these Config.cmake-files when building shared/static. From what I found online, I need to link static with static and shared with shared; but that is not possible as the Configs are overwriting each other.
Installing in different folders and then using find_package on both also doesn't work, as the package-name is the same for both shared and static (the .lib has a different name, but not the package).
As all the libraries I'm using have this overwrite, I thought it might be that my uneducated approach to this problem is flawed.
So, what is the standard way to use both the shared and static version of a library in a CMake-project; possibly switching between both with BUILD_SHARED_LIBS or a similar flag?
PS: Another thing I tried is pointing find_package to a different folder depending on BUILD_SHARED_LIBS. However, once the package is found, it is not re-searched, so I always and up with the folder associated with the default setting of this switch.
I have an issue where I'm developing on one system where Boost is installed on:
/usr/include
/usr/lib
On a system I will deploy this on, the libboost libraries are at:
/nfs/mount/boost
/nfs/mount/lib
And I can't go about changing every system I deploy on to install libboost in the same place.
Is there a way to either:
include libboost as part of the binary executable such that loading from the system lib paths is not needed.
make the executable search for different directories when trying to load to libboost?
I'm using g++ 8
Sounds like you need a more sophisticated build environment.
I'm not sure what you mean here:
include libboost as part of the binary executable such that linking is not needed
Linking is not something you can skip. If you are trying to avoid distributing .dll/.so files with your executable, you need to avoid using the portions of the boost library that require compilation of the boost binaries (i.e. those not listed here https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html#header-only-libraries).
Of course, that is not often the case. So...
make the executable search for different directories when trying to link to libboost?
This will never work reliably as you scale and is a nightmare in the CI world. This is where package managers such as conan (https://conan.io/) come to save the day. Delegating the package management to a third-party is the most reliable way of getting your code to build across multiple environments/platforms.
Also, building your executable and distributing it are separate operations. Any dynamically linked libraries will need to be discoverable on the system path at runtime.
This is my first time using cmake gui in windows. I am trying to install the vsomeip library in Windows. This is mainly required for my common API someip application. Now, I am having issue to compile the vsomeip library. When I run CMake gui, it says Could NOT find Boost (missing: system thread filesystem) (found suitable version "1.67.0", minimum required is "1.55")
I have already added the boost directory to my environment Path variable. I am not sure whether are there any additional configurations is required. When I try the same in Linux, it works fine. Only in Windows there is an issue.
I fixed the issue by changing the boost version inside the boost/version.hpp.
Previously the version was written as 1_55_0. So I just changed the version to 1_55.
The other fixed was to add the environment variable Path. I added the boost include directory itself: C:\local\boost_1_55_0\boost
I am not sure this is the right way for the fix but this fixes worked for me. Maybe if you guys have better solution can share it here.
I'm having trouble building the Mongo legacy Cpp driver with the --SSL option on Windows.
The problem is that I'm using the prebuild versions of the Boost libraries thus as is detailed on the mongo driver build documentation page I must use the --libpath and --cpppath option to point to the boost libs and headers instead of the --extrapath option.
Due to the layout of the boost installation in the pre-built binaries,
you cannot use the --extrapath SCons flag to inform the build of the
installation path for the boost binaries. Instead, you should use the
--cpppath flag to point to the root of the chosen boost installation path, and --libpath to point into the appropriately named library
subdirectory of the boost installation.
But I also need the --libpath and --cpppath to point to the OpenSSL library.
I've tried:
Combining the paths with a ';' ex. --libpath="c:\boost-path\lib;c:\openssl-path\lib"
Specifying the --libpath and --cpppath twice, each with one
path
Set environment variables LIBPATH and CPPPATH
None seem to work, depending on what comes first I get a build warning about not finding Boost or not finding SSL.
How can I specify both?
The legacy driver build system honors several forms of setting the library and include search path. The one that you want to use here is the LIBPATH and CPPPATH Scons Variables, which are set after invoking SCons. Multiple arguments are separated with spaces within a quoted string. Try the following:
scons --ssl CPPPATH="c:\boost-path\include c:\openssl-path\include" LIBPATH="c:\boost-path\lib c:\openssl-path\lib"
I've been working on various open-source projects, which involve the following C++ libraries (& others):
MuPDF
Boost
FreeType
GTKmm
hummus PDF libraries
LibTiff
LibXML2
Wt xpdf
xpdf
Poppler
ZLib
It often takes a long time to configure these libraries, when setting them up on a clean machine. Is there a way to automate the grabbing of all dependencies on a windows machine?
The closest I've found is CMake, which checks to make sure you have the dependencies installed/extracted before generating your project files. But I haven't found anything for Windows which can parse the list of dependencies and then download+install the required versions.
Please recommend a package manager for Windows with up-to-date C++ libraries.
Vcpkg, a Microsoft open source project, helps you get C and C++ libraries on Windows.
Take a look at the Hunter package manager when you already use CMake to setup your project. It automatically downloads and builds your dependencies whith only a few lines of extra cmake code. Hunter is based on cmake export and import targets.
For example if you want to use the GoogleTest library in your cmake based project you would add the following lines to your root CMakeLists.txt
# file root CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
# To get hunter you need to download and include a single cmake file
# see documentation for correct name
include("../gate.cmake")
project(download-gtest)
# set the location of all your hunter-packages
set( HUNTER_ROOT_DIR C:/CppLibraries/HunterLibraries )
# This call automaticall downloads and compiles gtest the first time
# cmake is executed. The library is then cached in the HUNTER_ROOT_DIR
hunter_add_package(GTest)
# Now the GTest library can be found and linked to by your own project
find_package(GTest CONFIG REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo GTest::main)
Not all the libraries you list are available as "hunter-packages" but the project is open source so you can create hunter-packages for your dependencies and commit them to the project. Here is a list of libraries that are already available as hunter packages.
This will not solve all your problems out of the box because you have to create hunter-packages for your dependencies. But the existing framework already does a lot of the work and it is better to use that instead of having a half-assed selfmade solution.
Biicode is a new dependency manager for C++. It also has a few libraries that you listed. Biicode automatically scans your source files for dependencies, downloads and builds them. See here for a very cool example that includes Freeglut.
What I've found:
Closest thing to what I'm looking for:
NuGET
Unfortunately it doesn't have any of the libraries I require in its repository.
So I ended getting most of the libraries from the KDE4windows project and custom building the rest.
Npackd is a package manager for Windows. There is a default repository for C++ libraries and also a third party repository for Visual Studio 2010 64 bit libraries. Boost and zlib are already in the default repository. If you decide to use Npackd, you could file an issue if you need other libraries.
Windows does not have a package manager. Go to the libraries' website and download the Windows builds if they provide any.
There are some alternatives, but not without drawbacks:
Cygwin: provides a nice package manager, but all binaries are built for Cygwin, which means they run slower than their native equivalent, any apps using them will link to the Cygwin DLL, and you're stuck with that license. Also the use of the native Win32 API is sometimes troublesome due to incompatibility with the POSIX emulation offered. Only for GCC.
MinGW-get: is a package manager for the MinGW.org compiler. These are native Win32 binaries, but only for use with MinGW's GCC.
There is no package manager or slightly equivalent thing for anything Visual Studio or MinGW-w64 related.
There is no package management on Windows. On Windows developers typically use full-blown everything-and-the-kitchen-sink development environments and produce monolithic applications themselves, shipped with all dependencies.