如何使弱链接与 GCC 一起工作？

Question

似乎有 3 种方法告诉 GCC 弱链接符号：

• __attribute__((weak_import))
• __attribute__((weak))
• #pragmaweaksymbol_name code>

这些都不适合我：

#pragma weak asdf
extern void asdf(void) __attribute__((weak_import, weak));
...
{
    if(asdf != NULL) asdf();
}

我总是收到这样的链接错误：

Undefined symbols:
  "_asdf", referenced from:
      _asdf$non_lazy_ptr in ccFA05kN.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

我在 OS X 10.5.5 上使用 GCC 4.0.1。 我究竟做错了什么？

Answer 1

我只是对此进行了研究，并认为其他一些人可能会对我的发现感兴趣。

使用weak_import 的弱链接实际上只适用于动态库。 您可以让它与静态链接一起使用（通过指定上面建议的 -undefinedynamic_lookup ），但这并不是一个热门主意。 这意味着在运行时之前不会检测到未定义的符号。 就我个人而言，这是我在生产代码中要避免的事情。

下面是一个 Mac OS X 终端会话，展示了如何使其工作：

这是 fc

int f(int n)
{
    return n * 7;
}

这是 Whatnof.c

#include <stdio.h>
#include <stdlib.h>

extern int f (int) __attribute__((weak_import));

int main() {
    if(f == NULL)
        printf("what, no f?\n");
    else
        printf("f(8) is %d\n", f(8));
    exit(0);
}

从 fc 制作动态库：

$ cc -dynamiclib -o f.dylib f.c

编译并链接动态库，列出动态库。

$ cc -o whatnof whatnof.c f.dylib
$ otool -L whatnof
whatnof:
       f.dylib (compatibility version 0.0.0, current version 0.0.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

运行whatnof看看会发生什么：

$ whatnof
f(8) is 56

现在用一个空库（没有符号）替换f.dylib：

$ mv f.dylib f.dylib.real
$ touch null.c
$ cc -dynamiclib -o f.dylib null.c

运行相同的whatnof看看会发生什么：

$ whatnof
what, no f?

weak_import的基本思想（或“用例”）是它可以让你链接到一个集合动态（共享）库，但随后针对同一库的早期版本运行相同的代码。 您可以根据 NULL 检查函数，以查看代码当前运行的特定动态库是否支持它们。 这似乎是Xcode支持的基本开发模型的一部分。 我希望这个例子有用； 它让我对 Xcode 设计的这一部分感到放心。

Answer 2

将 -Wl,-flat_namespace,-undefined,dynamic_lookup 添加到用于执行最终链接的 gcc 编译器行。

Answer 3

最小可运行 Linux 示例

main.c

#include <stdio.h>

int my_weak_var __attribute__((weak)) = 1;

int main(void) {
    printf("%d\n", my_weak_var);
}

notmain.c

int my_weak_var = 2;

使用两个对象编译并运行：

gcc -c -std=c99 -Wall -Wextra -pedantic -o main.o main.c
gcc -c -std=c99 -Wall -Wextra -pedantic -o notmain.o notmain.c
gcc -std=c99 -Wall -Wextra -pedantic -o main.out main.o notmain.o
./main.out

输出：

2

不使用 notmain.o 编译并运行：

gcc -std=c99 -Wall -Wextra -pedantic -o main.out main.o
./main.out

输出：

1

GitHub 上游。

因此我们看到，如果在 notmain.o 上给出，那么非弱符号将按预期优先。

我们可以分析 ELF 目标文件 符号：

nm main.o notmain.o

给出：

main.o:
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T main
0000000000000000 V my_weak_var
                 U printf

notmain.o:
0000000000000000 D my_weak_var

然后：

man nm

包含：

符号类型。 至少使用以下类型； 其他也取决于目标文件格式。 如果是小写，则该符号通常是本地的； 如果大写，则该符号是全局的（外部）。 然而，有一些小写符号显示为特殊的全局符号（“u”、“v”和“w”）。

“D”
“d”符号位于初始化数据部分。

“V”
“v”符号是弱对象。 当弱定义符号与普通定义符号链接时，使用普通定义符号不会出现错误。 当链接未定义的弱符号且该符号未定义时，弱符号的值将变为零，不会出现错误。 在某些系统上，大写字母表示已指定默认值。

但是，如果处理 .a 静态库，您可能必须使用 -Wl,--whole-archive，如下所述：如何使 gcc 链接静态库中的强符号来覆盖弱符号?

弱符号也可以保留未定义，这在 Binutils 中会导致“平台特定行为”，请参阅：未解决的弱函数的 GCC 行为

在 Ubuntu 18.10、GCC 8.2.0 上测试。

Answer 4

您需要将 MACOSX_DEPLOYMENT_TARGET 变量设置为 10.2 或更高版本。 请参阅 Apple 文档 及其 关于弱链接的技术说明。

Answer 5

来自 gcc 文档手册：

弱

weak 属性导致声明作为弱值发出
符号而不是全局。 这主要用于定义
可以在用户代码中覆盖的库函数，尽管它
也可以与非函数声明一起使用。 弱符号是
支持 ELF 目标，并且在使用时也支持 a.out 目标
GNU 汇编器和链接器。

这意味着对象可以合法地覆盖弱符号（在另一个对象/库中定义），而不会在链接时出现错误。 不清楚的是您是否将库与弱符号链接。 看来您还没有定义符号并且库没有正确链接。