我正在构建一个共享/动态库。它在Linux和*BSD上运行，但在Mac OS X上，完全相同的编译和链接命令会产生未解决的引用错误。有什么好处？

Mac OS X在内部与Linux和*BSD非常不同。对象/可执行文件格式为

在Linux和*BSD上，当构建共享库时，默认情况下允许未解析的引用。期望它们在加载时能够满足主可执行文件和/或其他共享库的要求。如果在加载时无法解析这些符号，则共享库将无法加载。

在Mac OS X上，构建动态库时，默认情况下不允许未解析的引用。如果希望在加载时解析引用，则需要显式启用未解析的引用。这是使用未定义的dynamic_lookup链接器标志完成的。

在构建可加载插件时，允许未解析的引用非常有用。

使用链接器帮助诊断错误

大多数现代链接器都有一个冗长的选项，可以在不同程度上打印出来；

链接调用（命令行），关于链接阶段中包括哪些库的数据，库的位置，使用的搜索路径。

用于gcc和clang；通常会在命令行中添加-v-Wl、--verbose或-v-Wl和-v。更多详情请点击此处；

Linux ld手册页。LLVM链接器页。“GCC简介”第9章。

对于MSVC，/VERBOSE（特别是/VERBOSE：LIB）将添加到链接命令行。

/VERBOSE链接器选项上的MSDN页面。

模板实现不可见。

非专用模板的定义必须对使用它们的所有翻译单位可见。这意味着不能分离模板的定义到实现文件。如果必须分离实现，通常的解决方法是在头的末尾包含一个impl文件声明模板。常见的情况是：

template<class T>
struct X
{
    void foo();
};

int main()
{
    X<int> x;
    x.foo();
}

//differentImplementationFile.cpp
template<class T>
void X<T>::foo()
{
}

要解决这个问题，必须将X:：foo的定义移动到头文件或使用它的翻译单元可见的某个位置。

专用化模板可以在实现文件中实现，并且实现不必是可见的，但是必须事先声明专用化。

有关进一步的解释和另一种可能的解决方案（显式实例化），请参阅此问题和答案。

什么是“未定义的引用/未解析的外部符号”

我将尝试解释什么是“未定义的引用/未解析的外部符号”。

注意：我使用的是g++和Linux，所有示例都是针对它的

例如，我们有一些代码

// src1.cpp
void print();

static int local_var_name; // 'static' makes variable not visible for other modules
int global_var_name = 123;

int main()
{
    print();
    return 0;
}

and

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
//extern int local_var_name;

void print ()
{
    // printf("%d%d\n", global_var_name, local_var_name);
    printf("%d\n", global_var_name);
}

生成对象文件

$ g++ -c src1.cpp -o src1.o
$ g++ -c src2.cpp -o src2.o

在汇编程序阶段之后，我们有一个对象文件，其中包含要导出的任何符号。看看这些符号

$ readelf --symbols src1.o
  Num:    Value          Size Type    Bind   Vis      Ndx Name
     5: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    4 _ZL14local_var_name # [1]
     9: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 global_var_name     # [2]

我拒绝了输出中的一些行，因为它们无关紧要

因此，我们看到要导出的以下符号。

[1] - this is our static (local) variable (important - Bind has a type "LOCAL")
[2] - this is our global variable

src2.cpp不导出任何内容，我们没有看到它的符号

链接我们的对象文件

$ g++ src1.o src2.o -o prog

并运行它

$ ./prog
123

Linker看到导出的符号并将其链接起来

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
extern int local_var_name;

void print ()
{
    printf("%d%d\n", global_var_name, local_var_name);
}

并重建对象文件

$ g++ -c src2.cpp -o src2.o

好的（没有错误），因为我们只构建对象文件，链接还没有完成。尝试链接

$ g++ src1.o src2.o -o prog
src2.o: In function `print()':
src2.cpp:(.text+0x6): undefined reference to `local_var_name'
collect2: error: ld returned 1 exit status

发生这种情况是因为我们的local_var_name是静态的，即它对其他模块不可见。现在更深入。获取翻译阶段输出

$ g++ -S src1.cpp -o src1.s

// src1.s
look src1.s

    .file   "src1.cpp"
    .local  _ZL14local_var_name
    .comm   _ZL14local_var_name,4,4
    .globl  global_var_name
    .data
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; assembler code, not interesting for us
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
    .section    .note.GNU-stack,"",@progbits

所以，我们看到local_var_name没有标签，这就是链接器找不到它的原因。但我们是黑客：），我们可以修复它。在文本编辑器中打开src1.s并更改

.local  _ZL14local_var_name
.comm   _ZL14local_var_name,4,4

to

    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789

也就是说，你应该像下面这样

    .file   "src1.cpp"
    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789
    .globl  global_var_name
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; ...

我们已经更改了localvarname的可见性，并将其值设置为456789。尝试从中构建对象文件

$ g++ -c src1.s -o src2.o

好，请参阅readelf输出（符号）

$ readelf --symbols src1.o
8: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 local_var_name

现在local_var_name具有绑定GLOBAL（以前是local）

link

$ g++ src1.o src2.o -o prog

并运行它

$ ./prog 
123456789

好的，我们破解它：）

因此，当链接器在对象文件中找不到全局符号时，就会发生“未定义的引用/未解析的外部符号错误”。

需要考虑的一些拼写错误：（我作为初学者经常遇到）

如果您使用的是类：请检查您是否没有在定义函数的cpp文件中的函数名之前忘记“classname:：”。如果使用forward声明：请确保声明正确的类型。例如：如果要转发声明“结构”，请使用“结构”而不是“类”。

在链接共享库时，请确保未隐藏使用的符号。

gcc的默认行为是所有符号都可见。但是，当使用选项-fvisibility=hidden构建转换单元时，只有标记为__attribute__（（可见性（“默认”））的函数/符号在生成的共享对象中是外部的。

您可以通过调用以下命令来检查要查找的符号是否为外部符号：

# -D shows (global) dynamic symbols that can be used from the outside of XXX.so
nm -D XXX.so | grep MY_SYMBOL 

隐藏/本地符号用小写符号类型的nm表示，例如t而不是代码段的“t”：

nm XXX.so
00000000000005a7 t HIDDEN_SYMBOL
00000000000005f8 T VISIBLE_SYMBOL

您还可以使用nm和选项-C来定义名称（如果使用了C++）。

与Windows DLL类似，可以使用define标记公共函数，例如DLL_public定义为：

#define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

大致对应于Windows的/MSVC版本：

#ifdef BUILDING_DLL
    #define DLL_PUBLIC __declspec(dllexport) 
#else
    #define DLL_PUBLIC __declspec(dllimport) 
#endif

有关可见性的更多信息可以在gcc wiki上找到。

---

当使用-fvisibility=hidden编译翻译单元时，生成的符号仍然具有外部链接（以大写符号类型显示，单位为nm），如果对象文件成为静态库的一部分，则可以毫无问题地用于外部链接。只有当对象文件链接到共享库中时，链接才会变为本地链接。

要查找对象文件中隐藏的符号，请运行：

>>> objdump -t XXXX.o | grep hidden
0000000000000000 g     F .text  000000000000000b .hidden HIDDEN_SYMBOL1
000000000000000b g     F .text  000000000000000b .hidden HIDDEN_SYMBOL2