[OE-core] [PATCH] boost.inc: make libboost_python3.so available

[Burton, Ross]

Right.

This was a change in Boost 1.67 onwards:

https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71#diff-42dd6ec1330a7c47aaccf2ab2b8f1e02

OpenCV has a patch to "fix" (bodge) the Py2 build:

https://github.com/ros-perception/vision_opencv/pull/239

But this doesn't work for Py3.  Boost and CMake consider this change
correct and the documentation for the cmake/boost integration reflects
this:

https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L43

So the worst-case fix is to patch opencv to look for "python35"
instead of "python3", although this will break when we upgrade to
Python 3.  A better solution would be to upstream a patch that uses
the Python version to generate the correct name.

Ross

On Tue, 16 Oct 2018 at 11:38, Burton, Ross <ross.burton at intel.com> wrote:
>
> On Tue, 16 Oct 2018 at 11:01, <richard.purdie at linuxfoundation.org> wrote:
> > I'm a little worried about why we're having to create these links when
> > other software seems able to expect these things by default. Is this
> > some standard packaging most distros do? I'm a little worried we're
> > creating an ABI here which doesn't exist...
>
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=14904908 says that
> Fedora's boost-python3 package contains just
> /usr/lib64/libboost_python3.so.1.66.0.  Their spec file at
> https://src.fedoraproject.org/rpms/boost/blob/master/f/boost.spec is
> hairy (as one expects for Boost) but doesn't appear to rename the
> file.
>
> So the question is why does our build produce libboost_python35.so?
>
> Ross