主页 / coding / 问题 / 79028257
Accepted
Steven Dickinson
Asked: 2024-09-27 00:22:30 +0800 CST

链接到具有相同符号的多个库时出现问题

  • 772

我有 2 个共享对象库，例如libA.so和libB.so。我有一个可执行文件，它从这两个库中调用函数，例如funcA()来自libA和funcB()来自libB。

不幸的是，libA和都libB具有一些使用相同符号名称的其他函数，例如libA具有函数f1()和f2()并且libB还具有函数f1()和。请注意，libA和libB之间的和的f2()实现完全不同，它们只是同名而已。f1()f2()

可执行代码从来不会直接调用f1()或f2()，当然libA应该只调用它的f1()& f2()，并且libB应该只调用它的f1()和f2()。

但是，似乎出了点问题，我在运行可执行文件时遇到了段错误。

我对此有一个解决方案，即在构建libA和时使用“version.script” libB，这样只公开外部 API 函数（即名为“func*”的函数），即以下脚本...

{
    global: func*;
    local: *; 
};

...并-Wl,--version-script=version.script在与 gcc 链接时使用。

这是可行的，但它确实给我带来了麻烦，因为我必须使用第三方工具链，这使得使用此 version.script 方法变得复杂（即 hacky）。

libA有没有更好/其他的方法？（注意，我确实有和的源代码libB，因此可以更改符号名称，但不喜欢，因为此代码是由第三方工具自动生成的，而且我并不想进入并编辑所有名称。当然，真正的代码不仅仅是和，f1()而是f2()数百个类似名称的符号）。

另外，我想了解问题的根本原因？我假设libA（或libB）对应该调用哪个f1()或感到“困惑” f2()，但为什么——由于libA和libB都是单独编译的——我怀疑这与共享对象库有关？

以防万一...库和可执行文件的源代码是 C，并使用 gcc 进行编译和链接，这是在 Linux 上。

gcc

1 个回答

  1. Best Answer

    首先，对您的问题进行最简化的说明。为了保持最小，我将矛盾函数从 减少f1()到f2()。f1()由于您说：

    我想了解问题的根本原因？

    我将使用最简洁的例子来解释这一点。然后我将展示如何在没有版本脚本的情况下避免这种情况。

    示例

    源文件和头文件libA.so：

    // A.h
#pragma once
extern void funcA(void);

// A.c
#include <stdio.h>
#include "A1.h"

void funcA(void)
{
    puts(__FUNCTION__);
    f1();
}
    
// A1.h
#pragma once
extern void f1(void);

// A1.c
#include <stdio.h>
#include "A1.h"

void f1(void)
{
    printf("%s from A1.c\n",__FUNCTION__);
}

    源文件和头文件libB.so：

    // B.h
#pragma once
extern void funcB(void);

// B.c
#include <stdio.h>
#include "B1.h"

void funcB(void)
{
    puts(__FUNCTION__);
    f1();
}
    
// B1.h
#pragma once
extern void f1(void);

// B1.c
#include <stdio.h>
#include "B1.h"

void f1(void)
{
    printf("%s from B1.c\n",__FUNCTION__);
}

    程序来源：

    // prog.c
#include <A.h>
#include <B.h>

int main(void)
{
    funcA();
    funcB();
    return 0;
}

    编译所有共享库源：

    $ gcc -c -fPIC A*.c B*.c

    程序源码如下：

    $ gcc -c -I . prog.c

    链接共享库：

    $ gcc -shared -o libA.so A*.o 
$ gcc -shared -o libB.so B*.o

    程序如下：

    $ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

    然后我们看到了你的问题：

    $ ./prog
funcA
f1 from A1.c
funcB
f1 from A1.c

    funcA和都funcB调用在中定义的f1from 。libA.soA1.c

    libA.so通过以相反的顺序重新链接程序libA.so：

    $ gcc -o prog prog.o -L . -lB -lA -Wl,-rpath=$(pwd)

    我们可以得出相反的问题：

    $ ./prog
funcA
f1 from B1.c
funcB
f1 from B1.c

    这并不是什么问题。

    解释

    矛盾函数符号在和的f1动态符号表中都有定义：libA.solibB.so

    $ readelf -W --dyn-syms libA.so

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)
     7: 0000000000001182    31 FUNC    GLOBAL DEFAULT   14 funcA
     8: 0000000000001159    41 FUNC    GLOBAL DEFAULT   14 f1
     
$ readelf -W --dyn-syms libB.so

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)
     7: 0000000000001159    41 FUNC    GLOBAL DEFAULT   14 f1
     8: 0000000000001182    31 FUNC    GLOBAL DEFAULT   14 funcB

    因此，在两个共享库中，它在运行时对于动态链接器都是可见的，作为对的引用的合格定义f1，并且动态链接器将默认将所有此类引用绑定到它在加载和链接构建过程中递归所需的共享库过程中找到的第一个定义。

    要运行prog，该构造从加载可执行文件 开始prog。查看其动态部分的顶部：

    $ readelf --dynamic prog

Dynamic section at offset 0x2d90 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/imk/develop/so/scrap]
 ...[cut]...

    这是静态链接器写入其中以供动态链接器读取和执行的信息。可执行文件需要按顺序加载libB.so和。 是运行时链接器可以搜索以查找所需共享库的目录（除了其默认搜索目录之外）。这是我添加到程序链接的结果（因为我不会费心正确安装这些一次性库）。libA.soRUNPATH /home/imk/develop/so/scrap-rpath=$(pwd)

    因此在这种情况下，动态链接器找到的第一个定义加载的共享库f1将是libB.so；这是来自的定义B1.c，它会将程序中的所有引用绑定到该定义。

    让我们恢复到原来的联系prog：

    $ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

    然后，正如您所猜测的，prog 的动态部分的顶部将显示：

    $ readelf --dynamic prog

Dynamic section at offset 0x2d90 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/imk/develop/so/scrap]
 ...[cut]...

    libA.so在 之前加载，libB.so并且libA的定义f1将是获胜的定义，正如我们所见。

    修复

    您的问题源于创建共享库时静态链接器的默认行为：共享库中对其定义的动态符号的引用不会预先绑定到内部定义1。有一个链接器选项将覆盖默认行为，使每个库调用其自己的定义f1。来自man ld（ld是静态链接器，由您代表调用以gcc执行链接）：

    -B 符号

    创建共享库时，将全局符号的引用绑定到共享库中的定义（如果有）。通常，链接到共享库的程序可以覆盖共享库中的定义。此选项仅在支持共享库的 ELF 平台上有意义。

    因此我们可以像这样重新链接共享库：

    $ gcc -shared -o libA.so A*.o -Wl,-Bsymbolic
$ gcc -shared -o libB.so B*.o -Wl,-Bsymbolic

    （顺便说一下，我们用-Wl,<ld-option>告诉gcc将选项ld-option直接传递给ld。）

    将程序与新库重新链接：

    $ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

    然后每个库调用自己的定义f1：

    $ ./prog
funcA
f1 from A1.c
funcB
f1 from B1.c

    您可能也可以通过使用 GCC 的动态可见性属性来解决该问题，但这需要对库中的源进行一些修改。

    1. GNU 链接器对共享库的这种行为是设计使然：它与库是静态库时发生的情况相同，符合 GNU 链接器使静态档案和共享库的符号解析看起来相似的努力。
    • 1

相关问题