Re: [release] Boost 1.73.0 Release Candidate 1

From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2020-04-27 20:47:36

On Mon, 27 Apr 2020 at 18:12, John Maddock via Boost <boost_at_[hidden]>
wrote:

>
> > Unless something comes up, I'm planning on making the 1.73.0 release
> > tonight/tomorrow morning
>
> Great!
>
> This may be one for a future release, but it's just been brought to my
> attention that some package managers have had issues with being unable
> to build 1.70 onwards... see
> https://bugzilla.redhat.com/show_bug.cgi?id=1558278, in particular 1.72
> gives:
>
> + ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel
> --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on
> pch=off python=3.8 stage
> Performing configuration checks
>
>      - default address-model    : 64-bit
>      - default architecture     : x86
> warning: non-free usage requirements <threading>multi ignored
> warning: in main-target mpi at
> /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6
> warning: non-free usage requirements <threading>multi ignored
> warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120
> warning: non-free usage requirements <threading>multi ignored
> warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145
> error: Name clash for
> '<p/builddir/build/BUILD/boost_1_72_0/stage/lib>libboost_serialization.so.1.72.0'
> error:
> error: Tried to build the target twice, with property sets having
> error: these incompatible properties:
> error:
> error:     -  none
> error:     -  <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config
> error:
> error: Please make sure to have consistent requirements for these
> error: properties everywhere in your project, especially for install
> error: targets.
>
> Does anyone know if this has been reported back to us and/or fixed?
>
>
It's caused by Fedora-specific patches, because we don't like some of the
Boost policies (e.g. not linking liboost_python.so to libpythonX.Y.so and
setting RPATHs in the libraries). Since it's due to our changes, I haven't
reported it as a bug in Boost, but I did ask for help here (and asked if
some of our changes could be optionally supported upstream, but that didn't
seem popular).

The problems have been resolved with Peter Dimov's expert guidance (thanks
again, Peter!)