When compiling GDB for a non-native target, in my case x86_64 host and aarch64 target, it fails to import zlib when python library is statically linked. (gdb) python >import zlib >print("hello world") >end Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /local/users/jc957059/gcc123/build/opt/toolchains/python-runtime/lib/python3.10/lib-dynload/zlib.cpython-310-x86_64-linux-gnu.so: undefined symbol: PyExc_MemoryError Error while executing Python code. (gdb) exit The python library is being statically linked to gdb, but the symbols are not being exported. Thus the PyExc_MemoryError symbol is missing when trying to import zlib. Looking at this in gdb/configure:21954 # Work around Python http://bugs.python.org/issue10112. See also # http://bugs.python.org/issue11410, otherwise -Wl,--dynamic-list has # no effect. Note that the only test after this that uses Python is # the -rdynamic/-Wl,--dynamic-list test, and we do want that one to be # run without -export-dynamic too. PYTHON_LIBS=`echo $PYTHON_LIBS | sed -e 's/-Xlinker -export-dynamic//'` We remove -export-dynamic and expect to add -rdynamic/--dynamic-list. However this is only added for native builds using configure.nat. gdb/configure:29677 # Import nat definitions. nat_makefile_frag=/dev/null if test "${gdb_native}" = "yes"; then . ${srcdir}/configure.nat nativefile=$NAT_FILE fi gdb/configure.nat:54 case ${gdb_host} in *linux*) ... LOADLIBES='-ldl $(RDYNAMIC)' I don't see this error for native builds since the -rdynamic flag is present during linking, but for non-native builds this fails. Shouldn't we be adding the -rdynamic flag for all builds? Manually setting LDFLAGS="-rdynamic" fixes this problem for me. uname -a: Linux stbirv-lnx-1 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) Thanks, Justin
Internally at AdaCore, we build gdb against a static libpython. Our build setup seems to add -export-dynamic to LDFLAGS to make this work. I think a clean patch to do this in gdb somewhere would be totally fine.
Seems like more of a 'build' component thing than 'gdb' or 'python'.