库中所有符号的显式名称修饰（也称为名称修饰）答案

【问题标题】：Explicit name mangling (also called name decoration) for all symbols in a library库中所有符号的显式名称修饰（也称为名称修饰）
【发布时间】：2019-07-16 14:06:39
【问题描述】：

有没有办法在用 c（或 cpp）编写的库中显式地进行名称修饰（也称为名称修饰）。我希望我的共享库的所有符号的名称都被修饰。

考虑这个问题： Two library of different versions in an application 在这里，如果我可以明确地将他们所有的名字都弄乱了，我想我可以解决这个问题。gcc 编译器本身可能有一些选项可以做到这一点。

【问题讨论】：

基本上，您提出的“名称修改”与您在另一个问题的 cmets 中提出的相同：重命名其中一个库中的符号。你已经拒绝了。
XY 问题？你为什么要搞砸东西？
C 不支持名称修改。您可能可以在 C++ 中做到这一点。
@AndrewHenle 我没有拒绝这个想法。实际上，我知道的唯一方法是使用 --default-symver ，而 --default-symver 并不完全是名称修饰。而且我不想重命名我的代码中的所有函数。我需要一些可以进行符号重命名或名称修改的东西，而无需太多代码更改。
@SergeyA 我需要名称修改来解决问题stackoverflow.com/questions/56947406/…

标签： c++ c linux shared-libraries static-libraries

【解决方案1】：

你的问题是：

有没有办法在用 c（或 cpp）编写的库中显式地进行名称修饰（也称为名称修饰）。我希望我的共享库的所有符号的名称都被修饰。

但是，我怀疑您使用的术语 name mangling 不恰当。名称修改与库发布版本无关。如果您打算对库中导出的每个对象进行版本控制，那么有很多问题需要回答。就个人而言，我会使用版本化的命名空间——但这只是因为我（还）没有被它所困扰。这是一个简单的例子：

namespace mylibrary {
namespace v1 {
class foo {};
}
using foo = v1::foo;
}

mylibrary::foo f; // mylibrary::v1::foo

...然后在以后的版本中...

namespace mylibrary {
namespace v1 {
class foo {};
}
namespace v2 {
class foo;
}
using foo = v2::foo;
}
mylibrary::foo newer_f; // mylibrary::v2::foo
mylibrary::v1::foo older_f;

当然，你可以有很多排列。还有很多需要注意的地方，特别是如果您有模板代码或使用 ADL。如果您发布的库的版本 1 具有一个定义 class foo，但版本 2 有一个不同的定义，那么这两个库将不兼容！这才是重点。

但是，如果我不正确并且您确实想在您的 C++ 库中强制执行 C++ 名称修改（这很奇怪，因为它应该默认完成），那么答案是双重的。首先，看一些相关的问题：

阅读是相关的，但不是因果关系。相关问题正在回答您的问题反向。

许多操作系统都是用 C 编写的，这就是为什么在包含系统标头时通常会看到 extern "C" 的原因。这也是为什么当您尝试使用在其库是用 C 而不是 C++ 编译的库中声明的内容时，有时会看到链接器抱怨缺少函数的原因。

所以要朝另一个方向（你的方向）：在你的头文件中，你可以将你的导出声明为extern "C++"。这告诉编译器在导入或导出对象时特别使用重命名。

使用extern "C++" 不会单独使用你的魔术。有一些 GCC 选项可以控制一些关于名称修改的更具体的功能。所以，其次，看看那些。 GCC 手册页的（外部链接）在这里：https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html

任何提及 ABI 的选项，例如 -fabi，都可能会影响您。 “-fabi”标志与“应用程序二进制接口”相关。您可能还想了解有关这些术语的更多信息。 What is an application binary interface 有一些很好的答案，描述了 ABI 是什么以及如何开始推理它们。 “-Wabi”将告诉 GCC 在检测到潜在的 ABI 冲突时发出警告。但是，就像所有的 C++ 一样，它也不是万无一失的。如果存在可能无法检测到的名称修改问题，我不会感到惊讶。如果您曾经混合使用异构编译器供应商或版本，则尤其如此。

重要的是：混合 ABI 可能会是一个大头疼的问题。我非常担心 ABI 不兼容被强制在一起并导致非常难以调试的未定义行为！

【讨论】：