11

我最近在使用 Haskell FFI 到 C/C++ 时遇到了 C++ 内联函数的问题。也就是说，g++ 并没有真正内联声明的函数inline，并为它们生成符号。最终，当 ghci 尝试加载调用内联函数的目标文件时，这会产生链接器错误：

Loading object (static) solveeq.o ... done
Loading object (dynamic) /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so ... done
final link ... ghc: solveeq.o: unknown symbol `_ZN5Eigen8internal19throw_std_bad_allocEv'

在这里，只有头文件的 Eigen C++ 库中的_ZN5Eigen8internal19throw_std_bad_allocEv一个inline函数以某种方式被视为真正的函数并被赋予链接器符号。solveeq.o是我的目标文件，它对那个函数进行（间接）调用。环境为 Ubuntu 12.04 64bit，ghc 7.4.1。

问题是这样的：我可以extern "C" 用来防止 C++ 修饰我自己的函数的函数名称。但是我不能/不应该更改其他人定义的 C++ 头文件（出于显而易见的原因）。在我看来，编译器不应该首先为这个内联定义创建一个函数来导致这个错误。原因很简单。如果有问题的函数是真正内联的，我不会收到链接器错误。如果编译器变得聪明并决定为它创建一个真正的函数，我会得到这样的错误（或者同一个函数的多个定义，正如我在别处读到的那样）。所以现在，编译/链接的正确性取决于编译器的心情。

另外，我认为像这样的链接器问题实际上破坏了仅包含标头的 C++ 库（它们吸引了它们的可移植性），因为现在它们不能使用extern "C".

这是 c++ 的设计问题还是只是 g++ 的问题？我的问题是，有没有办法防止 c++ 编译器或 g++ 不内联内联函数？例如，是否有一个命令行选项？（修改源代码是毫无疑问的，因为它们是库代码。）

另外，我很好奇 C++ STL 如何处理这个问题。它们也是仅标题吗？

4

4 回答 4

3

函数存在inline是对编译器的提示，只要编译器认为合适，编译器就会很乐意忽略它。inline一些编译器会对已声明但不是内联的函数发出警告，例如gcc的-Winline，但禁用所有内联函数必然是不可行的：有一些相当大的函数处理定义为模板的数据结构。所有隐含的模板代码都可以是内联的，并且这些模板的实例可以在多个翻译单元中发出。

与其试图硬塞 C++ 的行为以将其与其他工具集成，不如让其他工具变得聪明并忽略它不感兴趣的符号。特别是，如果它对不需要的inline函数实例化不感兴趣，它应该忽略这些。由于它们可以出现在多个翻译单元中，它们通常使用弱符号。当您nm -po your-object-file.o在 UNIX 系统上使用grep您的工具所冒犯的符号时，您应该看到它们使用不同于普通符号 ( T) 的东西标记。

另一种方法可能包括链接一个共享对象，该对象仅公开您实际想要公开的符号并将该对象与该工具一起使用。也就是说，虽然我知道这种方法是可行的，但我自己并没有真正使用过。

于 2014-12-25T03:31:46.040 回答
2

GCC 不是为此而设计的，最好解决问题的根本原因，而不是试图将工具硬塞进它不应该做的事情中。

无法加载弱符号是一个长期存在的 GHCi 错误。它已在 7.8.1 版本中修复（我检查了 7.8.3）。只需升级您的 GHC，问题就会消失。

如果您无法升级 GHC，您可以构建一个共享库并告诉 GCC 隐藏内联函数。这是通过-fvisibility-inlines-hidden标志完成的。我已经用 GHCi 7.0.1 检查过这个方法确实有效。您可能必须指定共享对象的绝对路径（即ghci /full/path/to/your.so），或者将共享对象放置在动态加载器可以找到它的某个位置。由于某种原因，相对路径不起作用。

于 2014-12-29T08:22:54.983 回答
2

正如另一个答案已经指出的那样，如果编译器决定不内联函数或方法，编译器将生成它，并将其放入目标代码文件中。这不会导致错误。据推测，编译器决定不内联特定函数的事实在这里不是您的问题。

我以前从链接器中看到过您看到的错误，这是一个非常具有误导性的错误消息。它真正告诉你的是你忘记了包含一个带有模板定义的头文件。假设你有：

小部件_decl_fwd.H：

template<typename C> void widget(C c_arg);

接着：

widget_decl_impl.H：

template<typename C> void widget(C c_arg)
{
     // Whatever widget() needs to do, here
}

然后，你天真地继续写：

小部件工厂.C：

#include "widget_decl_fwd.H"

void make_widgets(int n)
{
    widget(n);
}

然后你尝试编译它。它会编译得很好，但无法链接。编译器看到了模板函数的声明，但没有看到它的定义。因此，编译器将对 widget() 的调用作为外部符号引用。如果碰巧将其他链接在一起的模块拉入声明中，实例化模板函数并导出正确的符号，则链接可能会成功，但可能会由于未解析的符号而失败。

在这种情况下，内联函数类似于模板。因此，链接器抱怨来自未解析的符号solveeq.C

这意味着您需要检查solveeq.C包含的内容，并验证它实际上是从某个地方拉入了这个内联函数或模板的实际定义，而不仅仅是它的声明。如果标题包含令人困惑，请使用 -E 选项，然后 grep 输出。

于 2014-12-29T06:07:50.190 回答
1

如果您不想内联函数，可以选择

-fno-inline

“除了那些用 always_inline 属性标记的函数外，不要展开任何内联函数。这是不优化时的默认值”

还有对内联函数大小的更多控制

-finline-limit=n

n指令数在哪里

于 2014-12-28T05:57:50.777 回答