Building binary wheel using nuitka (missing -lpython3.5m)

[andrewleech]

Hi,
I'm a big fan of nuitka for compiling pure python into an optimised binary module.
https://github.com/kayhayen/Nuitka

I've been using it for some time on Windows with no issues distributing modules (wheels) but only just tried building linux wheels with manylinux container and keep running into linker failures.
Nuitka/Nuitka#81

The main compilation steps all seem to go well, but the final linker fails:

g++ -o mypkg.so -export-dynamic -Wl,-R,'/opt/python/cp35-cp35m/lib' -Wl,--disable-new-dtags 
-Wl,-b -Wl,binary -Wl,/build/build/lib/mypkg.build/__constants.bin -Wl,-b -Wl,elf64-x86-64 
-Wl,-defsym -Wl,constant_bin=_binary__build_build_lib_mypkg_build___constants_bin_start 
-shared mypkg.build/module.mypkg.common.finder.os mypkg.build/module.mypkg.helpers.os 
<<SNIP FILE LIST>>
mypkg.build/fibers_x64.os mypkg.build/swapfiber.os -L/opt/python/cp35-cp35m/lib 
-lpython3.5m -ldl -lpthread -lutil -lm

/opt/rh/devtoolset-2/root/usr/libexec/gcc/x86_64-CentOS-linux/4.8.2/ld: cannot find -lpython3.5m

The low level build inside nuitka is orchestrated by scons if that helps at all.

I'm a little confused by other issues here relating to not linking against libpython.so, #85 or #69 as surely the compiler needs this to resolve all symbols?

I tried manually applying the patch in #87 (remove the -lpython ref in python-config) but it made no difference, same when removing the similar reference from the python-3.5 pkgconfig file. scons still adds that linker flag. But again, surely it needs a python library to link against?

Thanks.

[njsmith]

Python extension modules on Linux don't need to link against the Python library. The way shared libraries work on Linux, any extension modules can automatically access all the symbols exported by the main executable that's loading them. So the Python interpreter "injects" all the necessary symbols into extension modules at load time. (In fact, if you do link to some libpython.so, then all of its symbols actually get overwritten by the interpreter's when it's loaded.)

I don't know enough about how nuitka's build system works to comment on that part.

[mayeut]

this has been fixed upstream in nuitka: Nuitka/Nuitka@64a989b