[Bug 245835] math/kig python-kig.xml fails install when chosen python flavor is 3.7

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245835

--- Comment #6 from freebsd at patater.com ---
The FindBoostPython.cmake script appears to be having trouble detecting Boost
Python.

Does this line:
    find_package(Boost QUIET COMPONENTS python)

need to be changed to this?
    find_package(Boost QUIET COMPONENTS python3.7)


If I do that, I see that "Boost_PYTHON3.7_LIBRARY" is set to
"/usr/local/lib/libboost_python37.so" and "Boost_PYTHON3.7_FOUND" is set to
"ON". Without that change, the variables "Boost_PYTHON_LIBRARY" and
"Boost_PYTHON_FOUND" are not set (i.e. blank when printed with manually-added
CMake debug prints) after the "find_package(Boost QUIET COMPONENTS python)"
line.

However, even changing find_package() to look for the Boost python3.7 component
doesn't seem sufficient. It looks like Boost Python, for Python 3, has changed
APIs. Specifically, the build test that CMake is doing to see if the detected
BoostPython works is failing with:
ld: error: undefined symbol: boost::python::detail::init_module(char const*,
void (*)())

This is because that function has changed to the following, for Python 3,:
PyObject* boost:python::detail::init_module(PyModuleDef&, void(*)());

You can see that based on the version of Python being targeted, Boost will pick
either the old init_module API or the new one.
(https://www.boost.org/doc/libs/1_72_0/boost/python/module_init.hpp)

    #  if PY_VERSION_HEX >= 0x03000000

    BOOST_PYTHON_DECL PyObject* init_module(PyModuleDef&, void(*)());

    #else

    BOOST_PYTHON_DECL PyObject* init_module(char const* name, void(*)());

    #endif


There are two ways kig's CMake detects BoostPython. One is via using CMake and
then verifying with a build, the other is via pkg-config. Do you know if your
successful build used the CMake-detected BoostPython or if it went the
pkg-config detection route? (Although the ports Makefile modifies the CMake
detection route so I suspect CMake detection is the intended-to-work option.)


The output from "cmake --trace .." running in a "cmake_build2" folder inside
the kig working directory (/usr/obj/usr/ports/math/kig/work/kig-20.04.0 for
this test) is available at https://patater.com/cmake-trace.log (it's 3.2 MB,
over the attachment size limit).

I've attached the CMake error log which shows the build failure CMake
encounters when testing if it can use BoostPython.


Another strange thing I've noticed:
The test with CMake to see if BoostPython is usable has the following linker
option for libraries:
-Wl,-rpath,/usr/local/lib /usr/local/lib/libboost_python37.so
/usr/local/lib/libpython2.7.so

Why would it try to use libpython2.7.so? That doesn't seem right to me.


I'm not sure where to draw the line between fixing this problem with ports
(e.g. ${REINPLACE_CMD}) vs fixing it upstream. I'm happy to raise this upstream
if the problem is legitimate.

Thanks for the help.

-- 
You are receiving this mail because:
You are the assignee for the bug.