#56294: boost: update to 1.67.0
Reporter: michaelld | Owner: (none)
Type: update | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: | Port: boost
Boost 1.67.0 is out 14-Apr-2018. Updating from current (1.66.0_3) seems to
work "out of the box", with just rev-bumps to dependent ports -- still
testing but so far so good for at least my ports. Attaching Portfile diff.
OK so there are some issues I'm coming upon with changes to
`boost::thread` and `boost::posix_time` ... hopefully it's just slopping
programming on the project's part. Or maybe the Boost folks fixed some
type conversation issues. I'll work on fixing & verify back backward
compatibility with (at least) boost 1.66.0.
> Boost 1.67.0 is out 14-Apr-2018. Updating from current (1.66.0_3) seems
> to work "out of the box", with just rev-bumps to dependent ports -- still
> testing but so far so good for at least my ports. Attaching Portfile
Boost 1.68.0 is out 09-Aug-2018, and builds with no significant changes to
the port patches or Portfile. 1.67.0 built with no significant changes to
the port patches or Portfile, but many dependent ports had a compatibility
issues with 1.67.0; hopefully the vast majority of those have been
resolved, given that it was out 14-Apr-2018 -- about 4 months ago.
Given the ~4 months for projects to fix their issues with Boost 1.67.0,
and possible more issues now with 1.68.0, let's test this release with
ports that require Boost to make sure the vast majority work. I would like
to get this updated Boost in place sooner rather than later, assuming
compatibility is good.
One major ABI naming change: the Boost::Python library is renamed to
include the major.minor Python version but with no "." ... so, "27" for
Python 2.7 and "36" for Python 3.6 (for 2.,7 was "libboost_python-
mt.dylib" is now "libboost_python27-mt.dylib"). Not sure if this is a
change from 1.67.0 or 1.66.0 ... but it's important since any project
using CMake to find Boost must now specify "python27" or "python36" as a
component to look for, not just "python" or "python2" or "python3";
guessing other build systems will be impacted as well.
> Boost 1.68.0 is out 09-Aug-2018, and builds with no significant changes
> to the port patches or Portfile. 1.67.0 built with no significant changes
> to the port patches or Portfile, but many dependent ports had a
> compatibility issues with 1.67.0; hopefully the vast majority of those
> have been resolved, given that it was out 14-Apr-2018 -- about 4 months
Boost 1.69.0 is out as of 12/12/2018.
Because the Portfile currently uses "--layout=tagged", the resulting
libraries names change from the Boost 1.68.0 to include an abbreviated
architecture (e.g., "x64" for Intel 64-bit; "p32" for PPC 32-bit); thus
for example, the prior naming might be "libboost_system-mt.dylib", while
the new naming is "libbboost_system-mt-x64.dylib". This slight change
combined with a defect in how CMake works with Clang results in the
FindBoost.cmake script failing to detect the new library names with
This issue is resolved by moving to "--layout=system", which reverts the
library names to just the minimum for each component; for example here
Most of the changes to this latest Boost itself seem to be compatible with
the ports I've tried building with it, once the Portfile is fixed to
properly detect the changed name. That said, the 10 or so ports I checked
pale compared with the total number of ports that depend on Boost (some
250 in total).
Verifying that "enough" of these ports build and function properly
"enough" is an arduous task. We in MacPorts have yet to determine a
reasonable approach to updating Boost, so the version provided in MacPorts
regularly lags the latest release. Please be patient.
Any update on the progress on this? I'm working on a project where my
collaborators are on Linux with 1.67, and constantly having to `git
stash`/`git stash pop` this patch in our CMake:
-find_package(Boost 1.65 REQUIRED COMPONENTS system context python27)
+find_package(Boost 1.65 REQUIRED COMPONENTS system context python)