One of these bugfixes protects you and the network from a cache invalidation issue that could allow an adversary with sufficient resources to cause a denial of service attack or chain fork.
The following bjam succeeds if you remove these two lines added by this patch. ./bjam toolset=gcc target-os=windows threadapi=win32 threading=multi variant=release link=static --user-config=--without-mpi --without-python -s NO_BZIP2=1 -s NO_ZLIB=1 --layout=tagged --build-type=complete --prefix=/home/ubuntu/out/staging/boost -j2 install Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. gcc.compile.c bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. "g " -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -f PIC -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o... ...skipped The very same commit you identified seems to also break manual configuration of an external zlib in boost 1.58.0 (and earlier I guess) as described by the documentation (
note: to enable them, add "using mpi ;" to your error: at /home/ubuntu/build/boost_1_54_0/tools/build/v2/kernel/modules.jam:107 error: Unable to find file or target named error: '/zlib//zlib' error: referred to from project at error: 'libs/iostreams/build' error: could not resolve project reference '/zlib' Performing configuration checks - zlib : no (cached) - zlib : no (cached) Component configuration: - atomic : not building - chrono : not building - container : not building - context : not building - coroutine : not building - date_time : not building - exception : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : building - locale : not building - log : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...patience... Setting ZLIB_BINARY, ZLIB_INCLUDE and ZLIB_LIBPATH previously allowed to specify an externally compiled version of zlib with custom binary name.
Using that same logic on the older releases page, 4.1.2 is only listed as a minimum in Boost 1.53, meaning you need to upgrade GCC to at least 4.4.7, attempting to use your repositories then upgrade boost.
Please be aware that you must not upgrade GLIBC, or you may break your system.
In any case the documentation doesn't seem to properly reflect the current library behavior.
Or maybe I'm just completely misunderstanding it which is always possible.
For my use-case the whole application and dependencies (including boost) are statically linked so I have to prevent trying to link multiple versions of it when zlib is used elsewhere.
Also this external zlib has a non-standard name (libzlib.a under linux instead of libz.a).
Even though you might have followed the instruction from How to install Hedge from Git and installed (Debian/Ubuntu package g -4.3), you might have forgotten to check if you installed the basic g package.