"AutoLoad failed" from plugins with Python 3.8

[kapsh]

Steps to reproduce

1. Build hexchat with -Dwith-python=python-3.8.
2. Run it.

Result

AutoLoad failed for: /usr/x86_64-pc-linux-gnu/lib/hexchat/plugins/python.so
 /usr/x86_64-pc-linux-gnu/lib/hexchat/plugins/python.so: undefined symbol: PyExc_RuntimeError

It worked before with python-3.7. Possibly related to https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build (TLDR: C extensions are no longer linked to libpython, use pkg-config --libs python-x.x-embed instead).

[mapreri]

Indeed doing

--- a/plugins/python/meson.build
+++ b/plugins/python/meson.build
@@ -1,6 +1,6 @@
 python_opt = get_option('with-python')
 if python_opt.startswith('python3')
-  python_dep = dependency(python_opt, version: '>= 3.3')
+  python_dep = dependency(python_opt+'-embed', version: '>= 3.3')
 else
   python_dep = dependency(python_opt, version: '>= 2.7')
 endif

is enough to have it link again against python 3.8 and then it properly loads. However I've been told it's "wrong if extensions are linked against the interpreter". For now I'm applying the above in Debian, lacking a better solution.

[kapsh]

@mapreri hello, can you please clarify what extensions were meant there (like, you know, any extensions or just hexchat plugins)?
Your patch works of course but it wouldn't suffice as generic solution — previous python3 versions lacking python-XX-embed.pc. I wonder if this issue should be adressed to meson developers in fact.

[mapreri]

see the "what's new" entry you linked above. It clearly says what to do regarding previous versions if the "embed" option is needed.

Regarding who said me that it's "wrong" is the python maintainer in debian, and I believe he is referring to all extensions in general since I never mentioned anything about hexchat. Note that I don't know any more details myself on this matter, google might just be more useful than me :\

[kapsh]

@mapreri it seems to me that they meant C extensions for python (third-party modules with native code). I understand the link above as "you don't have to link modules to libpython as it will be loaded by python itself before importing your module". Hexchat on the other hand is using cpython api without loading Python interpreter.

[kapsh]

@TingPing thanks for quick fix! I will test it tomorrow or so and report how it works.

[kapsh]

Sorry, this doesn't seem to work for me. Plugin built from 3871fba is still not linked to libpython.so and gives the same startup error.

❯ lddtree /usr/lib/hexchat/plugins/python.so                 
python.so => /usr/lib/hexchat/plugins/python.so (interpreter => none)
    libglib-2.0.so.0 => /usr/host/lib/libglib-2.0.so.0
        libpcre.so.1 => /usr/host/lib/libpcre.so.1
        libpthread.so.0 => /usr/host/lib/libpthread.so.0
            ld-linux-x86-64.so.2 => /usr/host/lib/ld-linux-x86-64.so.2
    libc.so.6 => /usr/host/lib/libc.so.6

Any idea why? I can provide additional logs when asked.

[TingPing]

It links against what pkg-config --libs python3-embed tells it to.

[kapsh]

Yeah, I understand. My pkg-config output looks correct:

pkg-config --libs python-3.8-embed 
-lpython3.8 

That becomes "libpython3.8.so" on Linux and it's also present in my installation.

/usr/x86_64-pc-linux-gnu/lib/libpython3.8.so -> libpython3.8.so.1.0
/usr/x86_64-pc-linux-gnu/lib/libpython3.8.so.1.0