c - 使用 GCC 驱动程序时，是什么使静态库“不兼容”？

Question

所以我想做的是在 Ubuntu 14.04 (x86_64) 上musl-libc基于目前可用的最新发布的 1.1.11 版本进行设置。

我所做的是：

为 GCC 安装 multilib 支持：sudo apt-get --no-install-recommends install gcc-multilib
分别为 32 位和 64 位配置库并将它们安装到单独的文件夹中：
- CFLAGS=-m32 ./configure --prefix=$HOME/bin/musl-32-bit --disable-shared --target=i386-linux-gnu && make && make install
- CFLAGS=-m64 ./configure --prefix=$HOME/bin/musl-64-bit --disable-shared --target=x86_64-linux-gnu

然后为了构建一个静态链接，我在生成的premake4对象上调用 GNU make 像这样：Makefilepremake4

make -j 8 CC=$HOME/bin/musl-32-bit/bin/musl-gcc ARCH=-m32 LDFLAGS="-v -static" verbose=1

这似乎适用于链接步骤，该步骤使用以下内容进行轰炸：

Linking Premake4
$HOME/bin/musl-32-bit/bin/musl-gcc -o bin/release/premake4 intermediate/gmake__/premake.o intermediate/gmake__/os_uuid.o intermediate/gmake__/os_pathsearch.o intermediate/gmake__/os_match.o intermediate/gmake__/os_chdir.o intermediate/gmake__/os_mkdir.o intermediate/gmake__/os_stat.o intermediate/gmake__/os_getversion.o intermediate/gmake__/premake_main.o intermediate/gmake__/os_isdir.o intermediate/gmake__/string_endswith.o intermediate/gmake__/os_isfile.o intermediate/gmake__/scripts.o intermediate/gmake__/path_isabsolute.o intermediate/gmake__/os_rmdir.o intermediate/gmake__/os_getcwd.o intermediate/gmake__/os_is64bit.o intermediate/gmake__/os_copyfile.o intermediate/gmake__/lstate.o intermediate/gmake__/ltable.o intermediate/gmake__/lgc.o intermediate/gmake__/lobject.o intermediate/gmake__/lcode.o intermediate/gmake__/lmathlib.o intermediate/gmake__/lbaselib.o intermediate/gmake__/lmem.o intermediate/gmake__/lfunc.o intermediate/gmake__/lparser.o intermediate/gmake__/ldblib.o intermediate/gmake__/lzio.o intermediate/gmake__/lstrlib.o intermediate/gmake__/lvm.o intermediate/gmake__/lauxlib.o intermediate/gmake__/llex.o intermediate/gmake__/lstring.o intermediate/gmake__/ldump.o intermediate/gmake__/ldebug.o intermediate/gmake__/loadlib.o intermediate/gmake__/lopcodes.o intermediate/gmake__/linit.o intermediate/gmake__/ldo.o intermediate/gmake__/lapi.o intermediate/gmake__/liolib.o intermediate/gmake__/loslib.o intermediate/gmake__/lundump.o intermediate/gmake__/ltm.o intermediate/gmake__/ltablib.o    -v -static -L. -s -rdynamic  -lm -ldl
Using built-in specs.
Reading specs from $HOME/bin/musl-32-bit/lib/musl-gcc.specs
rename spec cpp_options to old_cpp_options
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-m32' '-o' 'bin/release/premake4' '-v' '-static' '-L.' '-s' '-rdynamic' '-specs=$HOME/bin/musl-32-bit/lib/musl-gcc.specs' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 -dynamic-linker /lib/ld-musl-i386.so.1 -nostdlib -static -export-dynamic -z relro -o bin/release/premake4 -s $HOME/bin/musl-32-bit/lib/crt1.o $HOME/bin/musl-32-bit/lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L. -L$HOME/bin/musl-32-bit/lib -L /usr/lib/gcc/x86_64-linux-gnu/4.8/. intermediate/gmake__/premake.o intermediate/gmake__/os_uuid.o intermediate/gmake__/os_pathsearch.o intermediate/gmake__/os_match.o intermediate/gmake__/os_chdir.o intermediate/gmake__/os_mkdir.o intermediate/gmake__/os_stat.o intermediate/gmake__/os_getversion.o intermediate/gmake__/premake_main.o intermediate/gmake__/os_isdir.o intermediate/gmake__/string_endswith.o intermediate/gmake__/os_isfile.o intermediate/gmake__/scripts.o intermediate/gmake__/path_isabsolute.o intermediate/gmake__/os_rmdir.o intermediate/gmake__/os_getcwd.o intermediate/gmake__/os_is64bit.o intermediate/gmake__/os_copyfile.o intermediate/gmake__/lstate.o intermediate/gmake__/ltable.o intermediate/gmake__/lgc.o intermediate/gmake__/lobject.o intermediate/gmake__/lcode.o intermediate/gmake__/lmathlib.o intermediate/gmake__/lbaselib.o intermediate/gmake__/lmem.o intermediate/gmake__/lfunc.o intermediate/gmake__/lparser.o intermediate/gmake__/ldblib.o intermediate/gmake__/lzio.o intermediate/gmake__/lstrlib.o intermediate/gmake__/lvm.o intermediate/gmake__/lauxlib.o intermediate/gmake__/llex.o intermediate/gmake__/lstring.o intermediate/gmake__/ldump.o intermediate/gmake__/ldebug.o intermediate/gmake__/loadlib.o intermediate/gmake__/lopcodes.o intermediate/gmake__/linit.o intermediate/gmake__/ldo.o intermediate/gmake__/lapi.o intermediate/gmake__/liolib.o intermediate/gmake__/loslib.o intermediate/gmake__/lundump.o intermediate/gmake__/ltm.o intermediate/gmake__/ltablib.o -lm -ldl --start-group /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a -lc --end-group /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o $HOME/bin/musl-32-bit/lib/crtn.o
/usr/bin/ld: skipping incompatible $HOME/bin/musl-32-bit/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make[1]: *** [bin/release/premake4] Error 1
make: *** [Premake4] Error 2

解决方案

事实证明，解决方案相当简单。

我们需要告诉链接器和驱动程序都使用-m32......我之前就是这么远。然而，事实证明缺少的部分是通过CFLAGS这样的方式将链接器选项传递给驱动程序-Wl,-melf_i386。

我终于能够在支持多库的 64 位主机上构建和链接 32 位可执行文件。

注意：以下信息留给那些想了解我如何调查该问题的人。

好的，所以我进一步调查了这个问题，一旦你提取了目标文件，输出就会变得更有启发性。要重现我正在做的事情，您可能必须使用 Bash 或允许的类似 shell，$(...)或者您需要相应地调整命令行。

首先，重要的是要安装gcc-multilib和安装朋友以便定位-m32（i386-linux-gnu这恰好是i686-linux-gnu这里的别名）。

代码和make文件

我有以下make文件：

CC?=$(HOME)/bin/musl/bin64/musl-gcc
BLDARCH?=-m64
CFLAGS+=-v $(BLDARCH)
LDFLAGS+=-v -static $(BLDARCH)

all: helloworld

helloworld: helloworld.c

clean:
    rm -f helloworld

rebuild: clean all

.PHONY: clean rebuild
.NOTPARALLEL: rebuild

和以下小helloworld.c：

#include <stdio.h>

int main(int argc, char** argv)
{
    printf("Hello world!\n");
    return 0;
}

和我的 32 位 musl-libc 分别安装到$HOME/bin/musl/{bin,include,lib}32。分别安装了64位$HOME/bin/musl/{bin,include,lib}64。

尝试构建：

make CC=$HOME/bin/musl/bin32/musl-gcc BLDARCH=-m32 rebuild

总是以同样的无意义的行失败：

/usr/bin/ld: skipping incompatible ~/bin/musl/lib32/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [helloworld] Error 1

挖掘细节

所以经过深思熟虑后，我决定重新gcc手动执行驱动程序完成的步骤。

这意味着大致运行（我用 a 替换了所有出现的主文件夹~）：

编译：/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -imultilib 32 -imultiarch i386-linux-gnu helloworld.c -nostdinc -isystem ~/bin/musl/include32 -isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/include -quiet -dumpbase helloworld.c -m32 -mtune=generic -march=i686 -auxbase helloworld -version -fstack-protector -Wformat -Wformat-security -o /tmp/ccGmMuR1.s
集合：as -v -v --32 -o /tmp/ccgRGlqf.o /tmp/ccGmMuR1.s
关联：env COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS="-v -v -static -m32 -o helloworld -specs=~/bin/musl/lib32/musl-gcc.specs -mtune=generic -march=i686" /usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 -dynamic-linker /lib/ld-musl-i386.so.1 -nostdlib -static -z relro -o helloworld ~/bin/musl/lib32/crt1.o ~/bin/musl/lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/32/crtbegin.o -L~/bin/musl/lib32 -L /usr/lib/gcc/x86_64-linux-gnu/4.8/32/. /tmp/ccpL09mJ.o --start-group /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc.a /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_eh.a -lc --end-group /usr/lib/gcc/x86_64-linux-gnu/4.8/32/crtend.o ~/bin/musl/lib32/crtn.o

显然，这并没有稍微改变错误消息：

/usr/bin/ld: skipping incompatible ~/bin/musl/lib32/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

所以我-lc从命令行中取出collect2并创建了一个文件夹，我将我的 musl-libc 构建尝试生成~/bin/musl/lib32/archive的整个文件提取到该文件夹中。libc.a然后我指示collect2在哪里可以找到这样的目标文件：

关联：env COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gc c/x86_64-linux-gnu/4.8/32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS="-v -v - static -m32 -o helloworld -specs=~/bin/musl/lib32/musl-gcc.specs -mtune=generic -march=i686" /usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 -dynamic-linker /lib/ld-musl-i386.so.1 -nostdlib -static -z relro -o helloworld $HOME/bin/musl/lib32/crt1.o ~/bin/musl/lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/32/crtbegin.o -L~/bin/musl/lib32 -L /usr/lib/gcc/x86_64-linux-gnu/4.8/32/. /tmp/ccpL09mJ.o --start-group /usr/lib/gcc/x86_64-linux-g nu/4.8/32/libgcc.a /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_eh.a --end-group /usr/lib/gcc/x86_64-linux-gnu/4.8/32/crtend.o ~/bin/musl/lib32/crtn.o $(find ~/bin/musl/lib32/archive -type f -name '*.o')

这个要点是取出-lc和附加$(find ~/bin/musl/lib32/archive -type f -name '*.o')。

这给了我一大堆新的，但更有意义的错误，类似于以下错误：

/usr/bin/ld: Warning: size of symbol `__init_ssp' changed from 1 in ~/bin/musl/lib32/archive/__libc_start_main.o to 65 in ~/bin/musl/lib32/archive/__stack_chk_fail.o
/usr/bin/ld: Warning: size of symbol `__funcs_on_exit' changed from 126 in ~/bin/musl/lib32/archive/atexit.o to 1 in ~/bin/musl/lib32/archive/exit.o
# more of those
/usr/bin/ld: i386 architecture of input file `~/bin/musl/lib32/crt1.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `~/bin/musl/lib32/crti.o' is incompatible with i386:x86-64 output
# more of those

情节变厚了。显然，该collect2命令对构建什么有错误的想法。考虑到管理环境变量的输出，这很奇怪：

COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-v' '-static' '-m32' '-o' 'helloworld' '-specs=~/bin/musl/lib32/musl-gcc.specs' '-mtune=generic' '-march=i686'

...我env在尝试重现collect2包装器在链接libc.a.

为了了解更多关于 GNU 编译器的内部结构，需要阅读https://gcc.gnu.org/onlinedocs/gccint/

不幸的是，关于collect2这里的部分对我们没有帮助。但冗长的输出/usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 --help看起来很有希望。

我们怎么能把我们的命令行选项偷运到collect2呢？

现在我打算满足于我可以手动运行的任何东西。所以我试图告诉链接器我期望的输出格式。基于我感兴趣的支持目标列表elf_i386。

-melf_386在上一行的末尾传递会产生一个有趣的错误输出。__vsyscall许多引用的函数，例如__moddi3和__divdi3未定义。这表明它们根本不存在于静态库的目标文件或任何启动.o文件中：

~/bin/musl/lib32/archive/aio.o: In function `cleanup':
aio.c:(.text+0x5ad): undefined reference to `__vsyscall'
aio.c:(.text+0x5bb): undefined reference to `__vsyscall'
aio.c:(.text+0x5e8): undefined reference to `__vsyscall'
aio.c:(.text+0x5f6): undefined reference to `__vsyscall'
aio.c:(.text+0x61d): undefined reference to `__vsyscall'
~/bin/musl/lib32/archive/aio.o:aio.c:(.text+0x62b): more undefined references to `__vsyscall' follow
~/bin/musl/lib32/archive/cpow.o: In function `cpow':
cpow.c:(.text+0x4f): undefined reference to `__mulxc3'
~/bin/musl/lib32/archive/cpowf.o: In function `cpowf':
cpowf.c:(.text+0x47): undefined reference to `__mulxc3'
~/bin/musl/lib32/archive/cpowl.o: In function `cpowl':
cpowl.c:(.text+0x4c): undefined reference to `__mulxc3'
~/bin/musl/lib32/archive/sysconf.o: In function `sysconf':
sysconf.c:(.text+0xcc): undefined reference to `__vsyscall'
~/bin/musl/lib32/archive/__getdents.o: In function `__getdents':
__getdents.c:(.text+0x13): undefined reference to `__vsyscall'
~/bin/musl/lib32/archive/opendir.o: In function `opendir':
opendir.c:(.text+0x37): undefined reference to `__vsyscall'
~/bin/musl/lib32/archive/readdir.o: In function `readdir':
readdir.c:(.text+0x1f): undefined reference to `__vsyscall'
~/bin/musl/lib32/archive/__init_tls.o: In function `__init_tls':
__init_tls.c:(.text+0x136): undefined reference to `__vsyscall6'
__init_tls.c:(.text+0x16e): undefined reference to `__vsyscall'

正如我在我的问题中已经澄清的那样，档案中的目标文件都表明它们是elf32-i386。

给定源文件in musl-libc: ，函数__vsyscall和__vsyscall6应该最终在一个名为的文件中。让我们先验证一下。由于还有一个文件，因此名称可能会有所不同。文件名中有四个文件：syscall.oi386src/internal/i386/syscall.ssrc/misc/syscall.csyscall

__syscall_cp.o
syscall_cp.o
syscall.o
syscall_ret.o

nm使用给查询这些文件：

$ nm -s $(ls |grep syscall)

__syscall_cp.o:
00000000 t sccp
         U __syscall
00000005 T __syscall_cp
00000000 W __syscall_cp_c

syscall_cp.o:
         U __cancel
00000008 T __cp_begin
00000035 T __cp_cancel
00000030 T __cp_end
00000000 T __syscall_cp_asm

syscall.o:
00000000 T syscall
         U __syscall_ret
         U __vsyscall6

syscall_ret.o:
         U __errno_location
00000000 T __syscall_ret

具有符号类型的符号U是未定义的，因此链接器期望来自外部（每个目标文件的外部）。

最终$ nm --defined-only *.o ../*.o|grep vsyscall需要验证这些符号确实从libc.a.

所以交叉构建libc.a了到底有什么问题。回到绘图板。

我希望这个描述可以帮助其他人找出类似的问题并了解 GCC 的幕后情况。

传奇还在继续

我真的很惊讶地看到：

$ nm --defined-only ../libc.a |grep -B 2 vsyscall
syscall.o:
0000004b T __syscall
00000000 T __vsyscall
00000031 T __vsyscall6

但对于提取的目标文件，相应的命令 ( nm --defined-only *.o ../*.o|grep -B 2 vsyscall) 将不会产生任何输出。

所以在里面libc.a不知何故nm看到了这两个符号，但在提取它们后它们消失了？奇怪的。

syscall.o让我们在中寻找libc.a：

$ nm ../libc.a |grep ^syscall
syscall.o:
syscall_ret.o:
syscall.o:
syscall_cp.o:

哇？那么syscall.o在静态库中存在两次？看起来这可能只是我们正在寻找的错误原因。它确实解释了为什么符号会消失。后者可能会syscall.o覆盖运行时第一次提取的那个ar x ...。

确认：

$ nm ../libc.a |grep -A 4 ^syscall\.o
syscall.o:
0000004b T __syscall
         U __sysinfo
00000000 T __vsyscall
00000031 T __vsyscall6
--
syscall.o:
00000000 T syscall
         U __syscall_ret
         U __vsyscall6

并在进行 32 位构建后查看 musl-libc 源代码树：

$ find . -type f -name 'syscall.o' -exec nm {} +

./src/internal/syscall.o:
0000004b T __syscall
         U __sysinfo
00000000 T __vsyscall
00000031 T __vsyscall6

./src/misc/syscall.o:
00000000 T syscall
         U __syscall_ret
         U __vsyscall6

lib32/archive以不与现有名称冲突的名称将前者复制到目录中会在其他函数上产生更多错误，这表明其他目标文件也可能在生成的libc.a.

哪些是重复的？

$ diff <(nm libc.a|grep ':$'|cut -f 1 -d :|sort) <(nm libc.a|grep ':$'|cut -f 1 -d :|sort -u)
--- /dev/fd/63  2015-10-05 23:58:53.683804823 +0000
+++ /dev/fd/62  2015-10-05 23:58:53.683804823 +0000
@@ -131,7 +131,6 @@
 clogl.o
 clog.o
 clone.o
-clone.o
 closedir.o
 close.o
 cnd_broadcast.o
@@ -1115,7 +1114,6 @@
 __syscall_cp.o
 syscall_cp.o
 syscall.o
-syscall.o
 syscall_ret.o
 sysconf.o
 sysinfo.o

通过这种方式，我们看到clone.o并syscall.o作为重复项受到影响。这表明libc.a对以下符号的给定未定义引用完全缺少某些目标文件：

__divdi3
__moddi3
__mulxc3
__tls_get_new
__udivdi3
__umoddi3

这些名称恰好与为 GCC 列出的整数库例程中的名称一致。这让我觉得我错过了 GCC 提供的一个链接库。喜欢libgcc？！...

我有包lib32gcc-4.8-dev，这意味着我应该有所需的文件：

$ apt-file list lib32gcc-4.8-dev|grep -E 'libgcc.*\.a'
lib32gcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc.a
lib32gcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_eh.a

在上一步之后，我决定在 Ubuntu 14.04 上设置一个 x86_32 版本，它基本上处于相同的补丁级别。

然后，我libgcc.a将 x86_32 机器上的数据与 x86_64 机器上的数据进行了比较。nm除了少数函数的“符号值”（行话）之外，它们几乎是相同的。

此外，由于符号在静态库中，我试图再次链接到静态库。这仅适用-melf_i386于链接器 ( collect2) 命令行。

在尝试使用LDFLAGS并注意到那些也被传递给cc1之后，我设置了附加-Wl,-melf_i386到CFLAGS并且现在它工作了。杰出的。

作为旁注：我还在/usr/lib/gcc/x86_64-linux-gnu/4.8/collect2命令行中ld交换了collect2应该是包装器的。错误输出是相同的。

c - 使用 GCC 驱动程序时，是什么使静态库“不兼容”？

2 回答 2

解决方案

代码和make文件

挖掘细节

传奇还在继续

哪些是重复的？

Related

Reference