静态库、链接和依赖项答案

【问题标题】：Static libraries, linking and dependencies静态库、链接和依赖项
【发布时间】：2009-06-12 07:18:27
【问题描述】：

我有一个要分发的静态库，其中包含 Foo.c/h，有人拿起它并将我的静态库包含在他们的应用程序中。

假设他们的应用程序中也有 Foo.c/h。他们会有链接错误吗？

【问题讨论】：

标签： c++ linker

【解决方案1】：

源文件的名称在链接过程中并不重要。

如果文件具有相同的内容，那么您将遇到问题，假设 .c 文件包含导出的符号（例如，非静态或非模板函数，或外部变量）。

【讨论】：

【解决方案2】：

这取决于。如果 foo.c 和 foo.h 定义了相同的函数和/或变量，那么是的，会有多个定义错误。如果它们只是具有相同的文件名，但包含不同的代码，则没有问题。

【讨论】：

【解决方案3】：

链接文件名
链接器本身的问题最少，但是如果添加了文件，一些 IDE 会抱怨 - 即使它们位于不同的文件夹中。但这通常不是什么大问题。

不要分发静态库（无源）

首先，您不应该单独重新分发静态库。代码 - 和兼容性 - 取决于编译器和许多常见设置，比如哪个运行时库（静态/动态、调试/发布，很高兴单线程从 VC 中消失了），一些 C++ 设置，如异常处理，虚成员函数指针表示等。您最终构建了数百个变体来仅支持主流编译器，而您最终仍然需要一些不同的人。

总是包含源代码，这样用户就可以在他的盒子上重建静态库。或者使用动态库 - 但它有自己的陷阱。

命名空间
如前所述，使用命名空间来避免冲突。不要太过分，如果您包含源代码，用户可以随时重新命名它。但请记住，using namespace 声明不应出现在标头中，因此需要稍微调整代码。

【讨论】：

【解决方案4】：

如果您提供静态库，则不需要包含 foo.c，因为这将是库的一部分，是的，如果他们有自己的 foo.c，它会混淆编译器和链接器，如果您这样做可能会导致问题两者都有类似的功能，否则将包含错误的标题。

解决此问题的最佳方法是为代码使用命名空间，从而保持其唯一性。

namespace myfooname
{

void foo()
{
//stuff
}


}

【讨论】：