With the abundance of Boost libraries available, it appears to be excessive to install all of them when only a few are needed, given that the total size is more than 750 MB unpacked. Is there a way to select and install a specific library instead ?
I couldn't find anything on boost documentation, except the bcp utility which assumes that boost is installed.
Libraries are packaged separately for Debian, Ubuntu, Arch, Conan, CMake, etc.
E.g. Doing apt-cache search reveals:
libboost-filesystem-dev - filesystem operations (portable paths, iteration over directories, etc) in C++ (default version)
libboost-program-options-dev - program options library for C++ (default version)
libboost-regex-dev - regular expression library for C++ (default version)
libboost-system-dev - Operating system (e.g. diagnostics support) library (default version)
libboost-thread-dev - portable C++ multi-threading (default version)
libboost-all-dev - Boost C++ Libraries development files (ALL) (default version)
libboost-atomic-dev - atomic data types, operations, and memory ordering constraints (default version)
libboost-chrono-dev - C++ representation of time duration, time point, and clocks (default version)
libboost-container-dev - C++ library that implements several well-known containers - dev files (default version)
libboost-context-dev - provides a sort of cooperative multitasking on a single thread (default version)
libboost-contract-dev - Contract library for C++ - dev files (default version)
libboost-coroutine-dev - provides a sort of cooperative multitasking on a single thread (default version)
libboost-date-time-dev - set of date-time libraries based on generic programming concepts (default version)
libboost-exception-dev - library to help write exceptions and handlers (default version)
libboost-fiber-dev - cooperatively-scheduled micro-/userland-threads (default version)
libboost-graph-dev - generic graph components and algorithms in C++ (default version)
libboost-graph-parallel-dev - generic graph components and algorithms in C++ (default version)
libboost-iostreams-dev - Boost.Iostreams Library development files (default version)
libboost-locale-dev - C++ facilities for localization (default version)
libboost-log-dev - C++ logging library (default version)
libboost-math-dev - Boost.Math Library development files (default version)
libboost-mpi-dev - C++ interface to the Message Passing Interface (MPI) (default version)
libboost-mpi-python-dev - C++ interface to the Message Passing Interface (MPI), Python Bindings (default version)
libboost-nowide-dev - Standard library functions with UTF-8 API on Windows development files (default version)
libboost-numpy-dev - Boost.Python NumPy extensions development files (default version)
libboost-python-dev - Boost.Python Library development files (default version)
libboost-random-dev - Boost Random Number Library (default version)
libboost-serialization-dev - serialization library for C++ (default version)
libboost-stacktrace-dev - library to capture and print stack traces - development files (default version)
libboost-test-dev - components for writing and executing test suites (default version)
libboost-timer-dev - C++ wall clock and CPU process timers (default version)
libboost-tools-dev - Boost C++ Libraries development tools (default version)
libboost-type-erasure-dev - C++ runtime polymorphism based on concepts (default version)
libboost-wave-dev - C99/C++ preprocessor library (default version)
Of course there will be interdependencies. E.g.
apt-cache depends libboost-filesystem1.74-dev
shows it depends on Boost System. Note it also depends on libstdc++ (transitively) via libboostx.yy-dev, which also suggests other boost libs, but none required.
BCP is a tool exclusively aimed at reducing the collected boost headers which in practice rarely has any use, because the headers themselves aren't as big and historically can not easily be omitted. Although over the years Boost is succeeding at reducing unnecessary inter-library dependencies, so you may find that it has more effect these days for your specific subset of libraries.
Related
I develop a utility in Go that requires recent version of sqlite. I'm interested only in targeting specific architecture, to be specific: x64 linux. I'm developing that utility on Mac OS X. I'm using go-sqlite3 driver. I use GNU Make + Glide to build my utility. In order to cross compile on my Mac I pass specific arch flags to make.
Repos on Linux platforms that I'm targeting usually have quite old versions of sqlite that don't have features that I need in my utility.
I can manually compile and install required version of sqlite on all the platforms that I need, but it is quite cumbersome. I wonder if there is a good way to either statically link a specific version of sqlite or somehow bundle a utility with specific version of sqlite dynamic library.
Even though I mention sqlite a lot, this question can be generalized to other libraries: how to bundle a golang app with a specific version of C library an outdated version of which may be installed on the target platform.
Also: how to better organize development of that utility so that other devs won't need to manually compile and install specific version of the library - the preference is to use Makefile that would build all the binaries for required target platform. I see that I can just copy code of specific version of library (e.g. sqlite) to my utility's repo though I wonder if there is a better option - maybe I can somehow use glide dependencies for that purpose and build library that I need as part of my other dependencies.
I have a vendor who supplies the SoC, associated BSP and some key middle-ware to us. Vendor uses gcc-4.9 to build all the delivered software.
The software delivered has two categories
Source packages: we get all sources and build ourselves.
Libraries and Binaries: we reuse what vendor delivers pre-built.
We plan to move to gcc-6.2, but vendor has no plans to move anytime soon.
So the questions arise:
For the pre-built binaries/libraries will there be ABI compatibility issues if we use gcc-6.2 and vendor delivers pre-builts with gcc-4.9. All the pre-built libs are shared objects.
Shall we expect compile time issues for the vendor's source packages (some packages have c as well as assembly), when we rebuild using gcc-6.2?
Target architecture is ARM.
We are putting together a Linux distribution.
I read about abicheck, I am considering to run abicheck for all the vendor delivered pre-builts (built with 4.9) and objects I build with 6.2.
Any pointers if this is the correct approach?
Other suggestions are equally welcome.
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.
Please tell me what difference between pthread versions: VC2, VCE2 and VSE2? How to choose which of them I must use with Visual C++ Express 2010 for Mongoose webserver library?
Thank you!!!
VCE - MSVC dll with C++ exception handling
VSE - MSVC dll with structured exception handling
VC - MSVC dll with C cleanup code
Which one you'd want to use with VC++ Express 2010 depends on how you want pthread clean up to be handled. If you're linking this to the Mongoose webserver (which I'm not familiar with), I think you'll want to use the exception handling model as that code is compiled with.
The pthreads Win32 library goes into a fair bit of detail:
Library naming
Because the library is being built
using various exception handling
schemes and compilers - and because
the library may not work reliably if
these are mixed in an application,
each different version of the library
has it's own name.
Note 1: the incompatibility is really
between EH implementations of the
different compilers. It should be
possible to use the standard C version
from either compiler with C++
applications built with a different
compiler. If you use an EH version of
the library, then you must use the
same compiler for the application.
This is another complication and
dependency that can be avoided by
using only the standard C library
version.
Note 2: if you use a standard C
pthread*.dll with a C++ application,
then any functions that you define
that are intended to be called via
pthread_cleanup_push() must be
__cdecl.
Note 3: the intention was to also name
either the VC or GC version (it should
be arbitrary) as pthread.dll,
including pthread.lib and libpthread.a
as appropriate. This is no longer
likely to happen.
Note 4: the compatibility number was
added so that applications can
differentiate between binary
incompatible versions of the libs and
dlls.
In general: pthread[VG]{SE,CE,C}c.dll
pthread[VG]{SE,CE,C}c.lib
where: [VG] indicates the compiler
V - MS VC, or G - GNU C
{SE,CE,C} indicates the exception
handling scheme SE - Structured EH,
or CE - C++ EH, or C - no exceptions
- uses setjmp/longjmp
c - DLL compatibility number
indicating ABI and API
compatibility with applications built against
any snapshot with the same compatibility number.
See 'Version numbering' below.
The name may also be suffixed by a 'd'
to indicate a debugging version of the
library. E.g. pthreadVC2d.lib.
Debugging versions contain additional
information for debugging (symbols
etc) and are often not optimised in
any way (compiled with optimisation
turned off).
For example:
pthreadVSE.dll (MSVC/SEH)
pthreadGCE.dll (GNUC/C++ EH)
pthreadGC.dll (GNUC/not dependent on
exceptions) pthreadVC1.dll (MSVC/not
dependent on exceptions - not binary
compatible with pthreadVC.dll)
pthreadVC2.dll (MSVC/not dependent on
exceptions - not binary compatible
with pthreadVC1.dll or pthreadVC.dll)
The GNU library archive file names
have correspondingly changed to:
libpthreadGCEc.a libpthreadGCc.a
If you want to see what the differences are for each of these clean up models, search for "__CLEANUP" in the pthreads Win32 source (there are only a few places where the different clean up models come into play).
I've been bundling JRE with my app by simply copying the files from $JAVA_HOME/jre to my app's distribution. This may be against the spirit of Java, but it reduces potential problems by ensuring that my app runs on a version of JRE that it was tested on (including the bitness; I use some JNI which requires that the JRE is a 32-bit version).
It works fine, but the whole distribution is somewhat big, so maybe some unnecessary files could be left out? Indeed, $JAVA_HOME/jre/README.txt contains the following advice:
The files that make up the Java SE Runtime Environment are divided into
two categories: required and optional. Optional files may be excluded
from redistributions of the Java SE Runtime Environment at the
vendor's discretion.
The following section contains a list of the files and directories that
may optionally be omitted from redistributions with the Java SE Runtime
Environment. All files not in these lists of optional files must be
included in redistributions of the runtime environment.
...When redistributing the JRE on Microsoft Windows as a private
application runtime (not accessible by other applications)
with a custom launcher, the following files are also
optional. These are libraries and executables that are used
for Java support in Internet Explorer and Mozilla family browsers;
these files are not needed in a private JRE redistribution.
What puzzles me is that the list of optional files includes, among others:
bin\java.exe
bin\javaw.exe
bin\javaws.exe
How can java/javaw.exe be optional? How am I supposed to start a Java application without them? Apparently I don't know something (likely), or the instructions are simply wrong.
When redistributing the JRE on Microsoft Windows as a private application runtime (not accessible by other applications) with a custom launcher, the following files are also optional.
If you embed the JVM (by linking against its shared libraries) in your own application, you do not need the standalone launcher executables. I think Eclipse works that way, for example.
If your app uses the java executable (via a batch file for example), then you need them, of course.
While this doesn't strictly relate to the question, for whole-program (or whole-platform) optimization of removing "un-needed code", I have found ProGuard to be a good tool. YMMV.