如何处理静态链接库之间的符号冲突？

Question

编写库时，最重要的规则和最佳实践之一是将库的所有符号放入特定于库的命名空间。由于namespace关键字，C ++使这很容易。在C中，通常的方法是在标识符前面加上一些特定于库的前缀。

C标准的规则放在那些一些限制（安全编译）：AC编译器可以看只是一个标识符的前8个字符，所以foobar2k_eggs并foobar2k_spam可能被解释为有效相同标识符-但是每一个现代的编译器允许任意长标识符所以在我们这个时代（21世纪），我们不应该为此烦恼。

但是如果你面对一些你无法改变符号名称/标识符的库呢？也许你只有一个静态二进制文件和标题或者不想要，或者不允许自己调整和重新编译。

Answer 1

C标准的规则对这些规则施加了一些限制（用于安全编译）：AC编译器可能只查看标识符的前8个字符，因此foobar2k_eggs和foobar2k_spam可以被有效地解释为相同的标识符 - 但是每个现代编译器都允许任意长标识符，所以在我们这个时代（21世纪），我们不应该为此烦恼。这不仅仅是现代编译器的延伸; 当前的C标准还要求编译器支持合理长的外部名称。我忘记了确切的长度，但如果我没记错的话，它就像31个字符。但是如果你面对一些你无法改变符号名称/标识符的库呢？也许你只有一个静态二进制文件和标题或者不想要，或者不允许自己调整和重新编译。然后你就被困住了。抱怨图书馆的作者。我曾经遇到过这样一个错误：我的应用程序的用户由于Debian的libSDL链接而无法在Debian上构建它libsoundfile，这至少在当时用可变的类似的方式污染了全局命名空间dsp（我小时候你不会！）。我向Debian抱怨，他们修复了他们的软件包并将修复程序发送到上游，我认为它已经应用了，因为我再也没有听说过这个问题。我真的认为这是最好的方法，因为它解决了每个人的问题。你做的任何本地黑客都会将问题留在库中，以便下一个不幸的用户再次遇到并与之抗争。如果你真的需要快速修复，并且你有源代码，你可以-Dfoo=crappylib_foo -Dbar=crappylib_bar在makefile中添加一堆等来修复它。如果没有，请使用objcopy您找到的解决方案。