跨模块.dll（编译器特定）错误地导入/导出方法/类。

MSVS要求您使用__declspec（dllexport）和__declsspec（dllimport）指定要导出和导入的符号。

这种双重功能通常通过使用宏来实现：

#ifdef THIS_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
#define DLLIMPEXP __declspec(dllimport)
#endif

宏THIS_MODULE只能在导出函数的模块中定义。这样，声明：

DLLIMPEXP void foo();

扩展到

__declspec(dllexport) void foo();

并且告诉编译器导出函数，因为当前模块包含其定义。当将声明包含在不同的模块中时，它将扩展到

__declspec(dllimport) void foo();

并且告诉编译器，该定义位于链接到的一个库中（另请参见1）。

您可以使用类似的导入/导出类：

class DLLIMPEXP X
{
};

尽管这是一个有多个公认答案的老问题，但我想分享如何解决一个晦涩的“未定义引用”错误。

不同版本的库

我使用别名来引用std:：filesystem：：path：filesystem自C++17以来就在标准库中，但我的程序也需要在C++14中编译，所以我决定使用变量别名：

#if (defined _GLIBCXX_EXPERIMENTAL_FILESYSTEM) //is the included filesystem library experimental? (C++14 and newer: <experimental/filesystem>)
using path_t = std::experimental::filesystem::path;
#elif (defined _GLIBCXX_FILESYSTEM) //not experimental (C++17 and newer: <filesystem>)
using path_t = std::filesystem::path;
#endif

假设我有三个文件：main.cpp、file.h、file.cpp：

file.h#include的＜实验：：filesystem＞，并包含上面的代码file.cpp，file.h的实现，#include的“file.h”main.cpp#include的<文件系统>和“file.h”

注意main.cpp和file.h中使用的不同库。由于main.cpp#在＜filesystem＞之后包含了“file.h”，所以这里使用的文件系统版本是C++17版本。我曾经用以下命令编译程序：

$g++-g-std=c++17-c main.cpp->将main.cpp编译为main.o$g++-g-std=c++17-c file.cpp->将file.cpp和file.h编译为file.o$g++-g-std=c++17-o可执行文件main.o file.o-lsdc++fs->链接main.o和file.o

这样，任何包含在file.o中并在main.o中使用的需要path_t的函数都会出现“未定义的引用”错误，因为main.o引用std:：filesystem：：path，而file.o引用的是std:：experimental：：filesystem:：path。

决议

为了解决这个问题，我只需要将file.h中的＜experimental：：filesystem＞更改为＜filesystem＞。

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

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

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

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

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

UNICODE定义不一致

Windows UNICODE构建时，TCHAR等被定义为wchar_t等。如果不使用UNICODE进行构建，则TCHAR被定义为char等。这些UNICODE和_UNICODE定义会影响所有“t”字符串类型；LPTSTR、LPCTSTR及其麋鹿。

构建一个定义了UNICODE的库，并试图将其链接到未定义UNICODE项目中，将导致链接器错误，因为TCHAR的定义将不匹配；char与wchar_t。

错误通常包括一个带有char或wchar_t派生类型的值的函数，这些类型也可能包括std:：basic_string<>等。浏览代码中受影响的函数时，通常会引用TCHAR或std:：basic_string<TCHAR>等。这是一个信号，表明代码最初用于UNICODE和多字节字符（或“窄”）构建。

要更正此问题，请使用UNICODE（和_UNICODE）的一致定义构建所有必需的库和项目。

这可以通过以下两种方式实现：；#定义UNICODE#定义UNICODE或在项目设置中；项目财产>常规>项目默认值>字符集或在命令行上；/DUNICODE/D-UNICODE

如果不打算使用UNICODE，请确保未设置定义，和/或在项目中使用了多字符设置，并始终应用。

不要忘记在“发布”和“调试”版本之间保持一致。

因为当涉及到链接器错误时，人们似乎都在关注这个问题，所以我将在这里添加这个问题。

GCC 5.2.0中出现链接器错误的一个可能原因是现在默认选择了新的libstdc++库ABI。

如果您在std:：__cxx11命名空间或标记[abi:cx11]中获得了有关符号未定义引用的链接器错误，则可能表明您正在尝试将使用_GLIBCXX_USE_cxx11_abi宏的不同值编译的对象文件链接在一起。这通常发生在链接到使用旧版本GCC编译的第三方库时。如果无法使用新的ABI重建第三方库，则需要使用旧的ABI重新编译代码。

因此，如果在5.1.0之后切换到GCC时突然出现链接器错误，这将是一件值得检查的事情。

已声明但未定义变量或函数。

典型的变量声明是

extern int x;

由于这只是一个声明，因此需要一个单独的定义。相应的定义如下：

int x;

例如，以下内容将生成错误：

extern int x;
int main()
{
    x = 0;
}
//int x; // uncomment this line for successful definition

类似的注释适用于函数。声明函数而不定义它会导致错误：

void foo(); // declaration only
int main()
{
   foo();
}
//void foo() {} //uncomment this line for successful definition

请注意，您实现的函数与您声明的函数完全匹配。例如，您可能有不匹配的简历限定符：

void foo(int& x);
int main()
{
   int x;
   foo(x);
}
void foo(const int& x) {} //different function, doesn't provide a definition
                          //for void foo(int& x)
                          

不匹配的其他示例包括

函数/变量在一个命名空间中声明，在另一个命名空间定义。函数/变量声明为类成员，定义为全局（反之亦然）。函数返回类型、参数编号和类型以及调用约定并不完全一致。

来自编译器的错误消息通常会给出已声明但从未定义的变量或函数的完整声明。将其与您提供的定义进行比较。确保每个细节都匹配。