我有一个 i386 debian 系统在 lxc 容器中运行。用户态是32位，内核是64位。因此配置检测到这一点：
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
这可能是从uname -m的输出中获取的
我有一个可以用 gcc 构建的软件包，结果是一个正确的 32 位二进制文件。不幸的是，在另一个 C++ 项目中我得到了这个：
configure:8595: checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries
从这里开始，链接器使用此开关，因此将尝试链接 64 位库而不是 32 位，但失败：
/usr/bin/ld: skipping incompatible /usr/lib/libboost_program_options.so when searching for -lboost_program_options
/usr/bin/ld: skipping incompatible /usr/lib/libboost_program_options.a when searching for -lboost_program_options
/usr/bin/ld: cannot find -lboost_program_options
collect2: ld returned 1 exit status
虽然库 .so 文件是正确的 32 位 ELF： …
我正在使用valgrind来调试通过dlopen使用可加载库的二进制文件.在debian stable上,stacktrace不包含可加载lib内调用的符号.
| | ->11.55% (114,688B) 0x769492C: ???
| | | ->11.55% (114,688B) 0x7697289: ???
| | | ->11.55% (114,688B) 0x769806F: ???
| | | ->11.55% (114,688B) 0x419812: myfunc (main.c:1010)
关于debian unstable的Valgrind工作正常,符号得到妥善解决.所以我开始寻找与众不同的东西.我在两个系统上都有这些软件包(valgrind从unstable更新为3.7):
ii valgrind 1:3.7.0-1+b1
ii libtool 2.2.6b-2
ii gcc 4:4.4.5-1
ii binutils 2.20.1-16
libs不会被剥离并包含debuginfo:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x33ffd210859178c15bb3923c5491e1a1b6065015, not stripped
仔细观察我注意到库的大小不同,在debian不稳定的情况下,lib稍微大些.将它们与readelf进行比较,调试信息的大小更大.
[26] .debug_aranges PROGBITS 0000000000000000 00a74c 000090 00 0 0 1
[27] .debug_pubnames PROGBITS 0000000000000000 00a7dc 000385 00 0 0 1 …