linux gcc链接的可执行文件缺少stat64的静态定义

一个linux stat64调用应该最终调用xstat64，并生成一个静态版本的stat64，该版本会随调用一起传递一个版本。linux gcc链接的可执行文件缺少stat64的静态定义

我们正在看到一个条件，其中调用stat64的C链接（gcc）版本链接到较旧版本的（C++链接）共享库（libdb2.so.1，使用stat64，但isn不应该提供它），而不是以stat64调用的“适当”静态版本结束。 ++的应用程序中的C具有我们所期望的：

00000000004007c8 <[email protected]>: 
    4007c8: jmpq *1051250(%rip)  # 501240 <_GLOBAL_OFFSET_TABLE_+0x20> 
    4007ce: pushq $0x1 
    4007d3: jmpq 4007a8 <_init+0x18> 

0000000000400ac0 <stat64>: 
    400ac0: push %rbp 
    400ac1: mov %rsp,%rbp 
    400ac4: sub $0x10,%rsp 
    400ac8: mov %rdi,0xfffffffffffffff8(%rbp) 
    400acc: mov %rsi,0xfffffffffffffff0(%rbp) 
    400ad0: mov 0xfffffffffffffff0(%rbp),%rdx 
    400ad4: mov 0xfffffffffffffff8(%rbp),%rsi 
    400ad8: mov $0x1,%edi 
    400add: callq 4007c8 <[email protected]> 
    400ae2: leaveq 
    400ae3: retq

而GCC链接的代码（也链接到我们的libdb2共享库）结束了一个全球参考stat64中，而不是它是假设的“静态”版本有：

0000000000400618 <[email protected]>: 
    400618: jmpq *1050146(%rip)  # 500c40 <_GLOBAL_OFFSET_TABLE_+0x20> 
    40061e: pushq $0x1 
    400623: jmpq 4005f8 <_init+0x18>

相同的代码，也当用gcc的时候不要链接到我们libdb2库链接，最终与预期的“静态” stat64中功能：

0000000000400550 <[email protected]>: 
    400550: jmpq *1050170(%rip)  # 500b90 <_GLOBAL_OFFSET_TABLE_+0x20> 
    400556: pushq $0x1 
    40055b: jmpq 400530 <_init+0x18> 

00000000004007b0 <stat64>: 
    4007b0: mov %rsi,%rdx 
    4007b3: mov %rdi,%rsi 
    4007b6: mov $0x1,%edi 
    4007bb: jmpq 400550 <[email protected]>

编辑：更多的我nfo从链接器映射获得（-Wl， - print-map）

当gcc链接的exe文件没有链接到我们的（libdb2）共享库时，我们看到它从libc_nonshared.a获取它的stat64文件：

/usr/lib64/libc_nonshared.a(stat64.oS) 
           /home/hotellnx94/peeterj/tmp/cc2f7ETx.o (stat64) 
... 

.plt   0x0000000000400530  0x70 
*(.plt) 
.plt   0x0000000000400530  0x70 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crt1.o 
       0x0000000000400540    [email protected]@GLIBC_2.2.5 
       0x0000000000400550    [email protected]@GLIBC_2.2.5 
       0x0000000000400560    [email protected]@GLIBC_2.2.5 
       0x0000000000400570    [email protected]@GLIBC_2.2.5 
       0x0000000000400580    [email protected]@GLIBC_2.2.5 
       0x0000000000400590    [email protected]@GLIBC_2.2.5 

.text   0x00000000004007b0  0x10 /usr/lib64/libc_nonshared.a(stat64.oS) 
       0x00000000004007b0    stat64

然而，一旦我们链接到我们的共享库（libdb2），这些符号是从crt1.o捡起来代替lib_nonshared.a：

.plt   0x00000000004005f8  0x70 
*(.plt) 
.plt   0x00000000004005f8  0x70 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crt1.o 
       0x0000000000400608    [email protected]@GLIBC_2.2.5 
       0x0000000000400618    stat64 
       0x0000000000400628    [email protected]@GLIBC_2.2.5 
       0x0000000000400638    [email protected]@GLIBC_2.2.5 
       0x0000000000400648    [email protected]@GLIBC_2.2.5 
       0x0000000000400658    [email protected]@GLIBC_2.2.5

什么我们也不会做（或将有一直在做，因为我们没有看到这在我们的图书馆的新版本中），这会导致lib_nonshared.a不再b e消费者链接到我们的图书馆后共享吗？

来源

2013-05-10 Peeter Joot

事实证明，这是由于一个英特尔编译器错误已修复。当我们开始使用具有修补程序的编译器版本时，由于新版本的intel编译器（生成有问题的共享库），因此我们遇到了二进制兼容性问题，因此无法正确导出此stat64符号。

来源

2013-10-29 17:55:59

linux gcc链接的可执行文件缺少stat64的静态定义

回答

相关问题