cocotb: libgpilog.so: undefined symbol: PyGILState_Release
Greetings. Current master (currently at 5a53f6b) is broken for me (Arch Linux w/ Python 3.8.5).
E.g., running test_vhdl_access returns:
[...]
/usr/bin/ghdl -r --workdir=sim_build --work=dec_viterbi dec_viterbi_ent --vpi=/home/nicola/.local/lib/python3.8/site-packages/cocotb/libs/libcocotbvpi_ghdl.so
loading VPI module '/home/nicola/.local/lib/python3.8/site-packages/cocotb/libs/libcocotbvpi_ghdl.so'
/home/nicola/.local/lib/python3.8/site-packages/cocotb/libs/libgpilog.so: undefined symbol: PyGILState_Release
/usr/bin/ghdl:error: cannot load VPI module
[...]
Same for iverilog. git bisect tells me that the responsible commit is 606f2485b082c917195f20b7e5b23ad8dcacd82a by @tpambor (indeed, reverting 606f2485b082c917195f20b7e5b23ad8dcacd82a and ef181522e26c4da6d52ed9443fcbf775155098d5 fixes the issue).
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (16 by maintainers)
Lazy binding of global data does not work but the solution here would be that the embedding library is linked to
libpython, therefore no runtime loading, lazy binding, etc. here but we still have control over loadinglibpythonif we load it before the first library dependent onlibpythonis loaded. If the embedding library is loaded, it will skip loadinglibpythonfrom disk because these symbols are already present in the process space.I’m fine with reverting.
Archlinux:
Debian:
On Archlinux non-PLT relocations (
R_X86_64_GLOB_DAT) are used for python symbols which cannot be lazy bound whereas on Debian PLT relocations (R_X86_64_JUMP_SLO) are used.Archlinux passes:
-Wl,-z,now:Library loading looks for me like this: