64位Ubuntu18调试32位程序时GDB报libtinfo.so.5 ELF版本错误

在64位Ubuntu 18系统上搭建了32位开发环境，代码编译、链接均正常，生成的二进制文件dms可正常运行，但使用32位GDB调试时出现如下错误：

(gdb) run
Starting program: /usr/src/Duris/dms
/bin/bash: error while loading shared libraries: libtinfo.so.5: wrong ELF class: ELFCLASS32
During startup program exited with code 127.

经检查，涉及的所有文件/库均为正确的32位版本：

obr@melbourne:/usr/src/Duris$ file dms
dms: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=fdf6e191894c459ebb5abe9287841eafdc858fa5, with debug_info, not stripped
obr@melbourne:/usr/src/Duris$ file /usr/bin/gdb
/usr/bin/gdb: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=fd1c820fe9165e82c09af64b7dd4ae728347a179, stripped
obr@melbourne:/usr/src/Duris$ file /usr/lib/libtinfo.so.5
/usr/lib/libtinfo.so.5: symbolic link to /lib/i386-linux-gnu/libtinfo.so.5.9
obr@melbourne:/usr/src/Duris$ file /lib/i386-linux-gnu/libtinfo.so.5.9
/lib/i386-linux-gnu/libtinfo.so.5.9: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=adf5caf5c1be713bfc7846377c08b3164ffa50ea, stripped
obr@melbourne:/usr/src/Duris$

解决方案 #

原因分析 #

错误根源是64位的/bin/bash被错误引导加载了32位的libtinfo.so.5。GDB启动目标程序时会调用bash作为shell，而当前环境变量（如LD_LIBRARY_PATH）可能优先指向了32位库目录，导致bash误加载不匹配的库版本。

临时修复（单次调试有效） #

启动32位GDB前重置LD_LIBRARY_PATH，避免32位库路径干扰：

LD_LIBRARY_PATH= /usr/bin/gdb /usr/src/Duris/dms

或者在GDB内部设置环境变量后再启动程序：

set environment LD_LIBRARY_PATH=
run

永久修复 #

创建专用的32位GDB启动脚本，确保子进程不会继承错误的库路径：

1. 创建脚本文件gdb32.sh：

   #!/bin/bash
   unset LD_LIBRARY_PATH
   exec /usr/bin/gdb "$@"
   

2. 赋予执行权限：

   chmod +x gdb32.sh
   

3. 使用该脚本启动调试：

   ./gdb32.sh /usr/src/Duris/dms
   

补充验证 #

确保系统安装了64位版本的libtinfo5包，让bash能正常加载对应库：

sudo apt install libtinfo5:amd64

内容的提问来源于stack exchange，提问作者OBR_EXO