I have inherited some code which uses bpstl::allocator. Obviously, my predecessor had certain Boost libraries installed and I do not.
Which (Linux) package do I need to install in order for the code to compile?
I can't find a DoxyGen or other navigable Boost documentation online.
Likely, bpstl is just a namespace alias. If I were to guess, I'd say
boost pool
boost container
boost interprocess
There's not a wellknown library that uses bpstl as a namespace (not even obsolete, that I remember) so, in all likelihood, such aliases can be found in the adjacent code base (headers) next to that code you inherited. It's gonna take some archaeology, but grep your way to it!
On debian-like Linuxen, by far the easiest way to get some mainstream version of boost installed is by
sudo apt-get install libboost-all-dev
Boost "navigable" documentation online is here: http://www.boost.org/doc/libs/1_57_0
Related
I am currently trying to install some packages for colmap according to https://colmap.github.io/install.html. But as I work in a conda environment, I try to install cgal using conda.
To me it is not really clear however which is the correct pendant to libcgal-dev in conda.
I found that there is a package on the conda-forge channel called cgal and one called cgal-cpp.
Can anyone tell me what is the difference between those two packages?
Since I got conflicts for the former, I installed the second one and thus, I am not sure if that contains all files that the libcgal-dev contains or if I still miss some files.
I think cgal-cpp contains all the usual C++ headers, while cgal contains the Python bindings.
First off I know there are several posts similar to this,but I am going to ask anyway. Is there a known problem with boost program_options::options_description in Debian "Buster" and Boost 1.67 packages?
I have code that was developed back in Debian 7, system upgraded to 8.3 then 8.11 now using Boost 1.55.
Code builds and runs. Now upgrade system to Debian Buster with Boost 1.67 and get the link errors for unresolved reference to options_description(const std::string& , unsigned int, unsigned int) along with several other program_options functions. All unresolved, expect the options_description, are from boost calling another boost function, so not even directly called from within my code. boost_program_options IS in the link line.
I AM not a novice and understand link order and this has nothing to do with link order.
I am going to try getting the source code for boost and building to see if that works, if not I will be building a system from scratch and testing against that.
Since this is all on a closed network simply saying try a newer version of boost or Debian is not an option because I am contractually obligated to only use Debian "Buster" and Boost 1.67 as the newest revisions, so if the package is unavailable (newer) in Buster it is out of the question, without having a new contract be drafted and go through approvals which could take months.
So to the point of this question, is there an issue with the out of the box version of Boost in Buster?
I don't think there's gonna be an issue with the package in Buster.
My best bet is that either
you're relinking old objects with the new libraries - and they don't match (did you do a full make clean e.g. to eliminate this possibility?).
Often build systems do not do complete header dependencies, so the
build system might not notice that the boost headers changed,
requiring the objects to be be rebuilt.
if that doesn't explain it, there could be another version of boost on the include path, leading to the same problem as under #1 even when rebuilding.
You could establish this by inspecting the command lines (make -Bsn or compile_commands.json e.g. depending on your tools). Another trick is to include boost/version.hpp and see what BOOST_VERSION evaluates to
Lastly, there could be a problem where the library was built with different compiler version or compiler flags, leading to incompatible synbols (this is a QoI issue that you might want to report with the Boost Developers).
This is assuming ABI/ODR issues, in case you want to validate this possibility.
It seems there were/are efforts to do this, but most of the resources I've seen so far are either outdated (with dead links) or have little to no information to actually build a small working sample (that, for example relies on boost program_options to build an executable).
Also, when using ExternalProject_Add, how does one resolve dependencies inside of Boost?
I'm basically looking to use Boost easily from within CMake with little to no manual configuration.
Try Hunter package manager:
hunter_add_package(Boost COMPONENTS regex system filesystem)
find_package(Boost CONFIG REQUIRED regex system filesystem)
target_link_libraries(foo PUBLIC Boost::regex Boost::system Boost::filesystem)
Note that usage of imported Boost targets is importand for relocatable packages
Wiki
Boost package
Relocation notes
Examples
Small
Big
Currently (August 2017) Boost libraries do not provide CMake support nor are they build using CMake. Boost has its own build system called b2. In July 2017 the Boost steering committee announced that all boost libraries should be moved to use CMake. This affects users and developers, i.e., CMake will be used internally to build the libraries and externally it will provide CMake config files.
As the build system question triggered heated discussions in the past years and there are strong feeling from part of the community against b2 and CMake, the outcome of this decision is unclear (first release with CMake, will all old libraries support CMake, even a split of the Boost community).
Original Answer from 2015
You can consider the effort to introduce CMake as a first-class citizen to boost as dead. See the mailing list thread about the topic.
If you don't want to use third party tools like hunter's package manager, check the most current verion of the boost library you want to use. Maybe you are lucky and it provides some CMakeLists.txt files you can use.
The most recent work on 'a boost which uses CMake and makes boost use ideal for CMake users' is here:
https://github.com/boost-cmake/boost-cmake
It requires cmake master branch (until CMake 3.0.0 is released soon) and I haven't attempted to build it in a while. Someone in the boost community would have to push forward with transitioning boost to CMake. The boost community might still be busy with transitioning to git.
I recently installed Debian Squeeze on my machine with C++ programming practice as one of the main goals. I use Boost libraries regularly in my projects. On OS-X and Windows, I had to manually install Boost header libraries prior to using them. However, regarding Linux, the front page of the Boost website mentions
Popular Linux and Unix distributions such as Fedora, Debian, and NetBSD include pre-built Boost packages.
I use mainly the header libraries, not pre-built packages for my current projects. So my question is: Are the header libraries installed by default anywhere on Debian or do I have to install them? I have already looked in /usr/include and it doesn't seem to have any Boost directory. I have googled as well as looked up related discussions on SO, but didn't get a clear answer to my question. If I do have to install the header libraries, is there an 'apt-get' way of doing it or I simply untar and place in a convenient location (/usr/local/include) ?
Second, if I need to manually place the boost headers (say in /usr/local/include/), should the version of the headers match with the pre-installed packages for compatibility with any potential future projects which use both the binaties (libboost-*) and header files?
I am fairly new to programming on a Linux platform. Although, I can make things work using patch-and-match (and googling), I am looking for guidance on long term best practices.
Thanks.
Saying a GNU/Linux distribution "includes" a package such as Boost doesn't mean it is installed automatically, it means the package is available for installation, using your system's package management tool. The package might be tailored for your distribution, so it integrates well with the rest of the OS, or it might just be identical to the upstream version and the benefit is just that it's already built for you and convenient to install from within the OS.
There is tons of documentation on Debian's package mgt tools:
http://wiki.debian.org/PackageManagement
http://www.debian.org/doc/manuals/debian-faq/ch-pkgtools.en.html
http://www.debian.org/doc/manuals/debian-reference/ch02.en.html
So yes, you want to apt-get (or the equivalent with another of Debian's tools) to install Boost in /usr/include, that will be much easier than manually installing them. If you later decide to install Boost manually, keep that installation entirely separate from the system packages, so the libraries and headers from the newer version don't conflict with the system packages. If it's a single-user machine and you don't need the packages to be available to other users on the machine then you can just install them in your home directory, rather than /usr/local/ (which requires superuser access, and you should do as little as possible as the root user)
Oh well, I can't find this easily. Could you let me know which of boost library includes boost spirit? Is it system or iostream?
Google for 'boost spirit site:boost.org' and you get right to the Boost Spirit page. Boost is a collection of libraries, this is one such library. You may want to read the introductory documents to learn about download and installation; several Linux distributions would include it premade.