Installation of dev-libs/boost[python] provides a bunch of shared libraries: libboost_python-${PYTHON_VERSION}. This seems to be not the standard way. I encountered an error with meson's boost module: Running compile: Working directory: /tmp/tmpgb2dvnp1 Command line: ccache c++ /tmp/tmpgb2dvnp1/testfile.cpp -pipe -D_FILE_OFFSET_BITS=64 -o /tmp/tmpgb2dvnp1/output.exe -O0 -fpermissive -Wl,--start-group -lboost_python3 -Wl,--end-group -Wl,--allow-shlib-undefined Code: int main(int argc, char **argv) { return 0; } Compiler stdout: Compiler stderr: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_python3 (with `boost_dep = dependency('boost', modules : ['python3'])` in meson.build as the documentation suggested) and found a similar situation here: https://github.com/BVLC/caffe/issues/4843 Of course I can file this as meson bug, too. However, I think the error is Gentoo specific. Would it be a solution to provide a symlink when setting a python interpreter with `eselect python`?
Ebuilds are not allowed to rely on which version of Python is selected by 'eselect python', but they should use appropriate functionality of Python-related eclasses. Packages using libboost_python* must use PYTHON_TARGETS and depend on dev-libs/boost:=[python,${PYTHON_USEDEP}] where ${PYTHON_USEDEP} is expanded into references to appropriate PYTHON_TARGETS USE flags. libboost_python-X.Y.so libraries are linked against libpythonX.Y.so. Providing a libboost_python.so or libboost_python3.so without embedded exact Python major/minor version in filename is not acceptable because it could hide inadequacies in build systems of some packages and it could allow run-time problems (mixing of multiple different libpythonX.Y.so libraries potentially leading to crashes). Similarly there is no unversioned libpython.so. See how other ebuilds in gentoo repository specify usage of appropriate libboost_python-X.Y.so library: $ grep boost_python $(find * -name "*.ebuild" | sort) If there is an inadequacy in Meson then you may file a bug about it. E.g. CMake's FindBoost.cmake searches for versioned libboost_python-X.Y.so.
Reported the bug on meson: https://bugs.gentoo.org/show_bug.cgi?id=675498 > Ebuilds are not allowed to rely on which version of Python is selected by 'eselect python' This is not what I ment. `eselect python` choose the "standard" Python version. When building locally using eg. Meson it is meaningful to link against this exact version. So what I meant is that `eselect python` creates the correct boost symlink when setting the Python version.
(In reply to gerion from comment #2) > Reported the bug on meson Correct URL: https://github.com/mesonbuild/meson/issues/4788 > `eselect python` choose the "standard" Python > version. When building locally using eg. Meson it is meaningful to link > against this exact version. So what I meant is that `eselect python` creates > the correct boost symlink when setting the Python version. But `eselect python` also does not create any /usr/lib/libpython.so symlink pointing to libpythonX.Y.so. There is no reason why it would create /usr/lib/libboost_python.so symlink. Until Meson is fixed, for your local outside-of-ebuild development, you might create a local symlink in location not used by ebuilds and set LDFLAGS. Example: $ mkdir /home/username/lib $ ln -s /usr/lib64/libboost_python-2.7.so /home/username/lib/ $ export LDFLAGS="-L /home/username/lib"
