On 2020-05-31 10:24, Honggang LI wrote:
On Fri, May 29, 2020 at 06:47:35PM +0200, Petr Viktorin wrote:
On 2020-05-18 03:53, Honggang LI wrote:
On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
rdma-core dledford honli jwilson
rdma-core pyverbs must be linked with libpython38. For example,
build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep -w
U | grep PyInterpreterState_GetID
U PyInterpreterState_GetID
Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep
PyInterpreterState_GetID
00000000000c6a82 T PyInterpreterState_GetID
This is exactly the case where the module should *not* be linked to
/usr/lib64/libpython3.8.so.
mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is loaded
from Python when imported. The import will link link it to the particular
Python interpreter it's imported into, which could be using a different
libpython3.8.so (such as the debug version).
OK, I see the problem now. But I don't know how to handle this.
Let's take ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so as
example.
1) Link with debug version.
[honli@localhost pyverbs (master)]$ gcc -fPIC -Wall -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition
-Wredundant-decls -O2 -g -DNDEBUG -Wl,--as-needed -Wl,--no-undefined -shared
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9d
[honli@localhost pyverbs (master)]$ ldd
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007fff2fbe4000)
libibverbs.so.1 =>
/home/honli/upstream/rdma-core/build/lib/libibverbs.so.1 (0x00007feed22c3000)
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x00007feed1e6e000)
libc.so.6 => /lib64/libc.so.6 (0x00007feed1ca3000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007feed1c1b000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007feed1bf7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007feed1bd5000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007feed1bcc000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007feed1bc7000)
libm.so.6 => /lib64/libm.so.6 (0x00007feed1a81000)
/lib64/ld-linux-x86-64.so.2 (0x00007feed22f7000)
[honli@localhost pyverbs (master)]$ ldd
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9d.so.1.0
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x00007f32570ac000)
[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9d.so.1.0
python3-debug-3.9.0~b1-3.fc33.x86_64
2) link with normal version
[honli@localhost pyverbs (master)]$ gcc -fPIC -Wall -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition
-Wredundant-decls -O2 -g -DNDEBUG -Wl,--as-needed -Wl,--no-undefined -shared
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9
[honli@localhost pyverbs (master)]$ ldd
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9
libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f7f8a7c7000)
[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9.so.1.0
python3-libs-3.9.0~b1-3.fc33.x86_64
As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to
the linker. Otherwise, a lot of "undefined reference to xxx" error
messages show up.
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:10425: undefined reference
to `PyErr_GivenExceptionMatches'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:8987: undefined reference to
`_PyObject_GenericGetAttrWithDict'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:7786: undefined reference to
`PyModuleDef_Init'
[honli@localhost pyverbs (master)]$ grep undefined error.txt |wc -l
876
Any hits how to handle this?
Judging from the file name, mem_alloc.cpython-38-x86_64-linux-gnu.so is
a Python module. If that's so, you shouldn't link it using gcc, but use
a Python import statement to load it.
Is there some reason to link it using gcc?
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
