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 <[email protected]> wrote: > > On Tue, 16 Oct 2018 at 11:01, <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
