由于缺少头文件而导致的段错误

Question

在构建共享对象时，我忘记将第三方“仅标题”库头（.h）文件放入正确的路径中。它建立得很好 - 回顾性地令人惊讶。

运行时，当我的共享对象中使用第三方lib时，就会发生段错误。

我不明白的部分是当我将这些头文件复制到#include指定的路径时，我不会导致段错误。我甚至没有重新构建对象。非常奇怪的是，当我将头文件放入dir时，它仍然有用 - 没有段错误。然而，当我完全对着这个目录时，它就崩溃了。它是否在当前目录和子目录中查找头文件？我还在标准（？）/usr/local/include

中获得了仅限标题的库

之前我没有使用过共享对象。我通常创建静态对象并将它们包含在构建中。我用来创建有问题的共享对象的标志是-shared -fPIC

我想了解这种行为。由于部署，这很有趣。在生产计算机上部署时是否需要包含这些头文件？基本上我不希望将它作为依赖项，因为它是一个“仅限标题”的库。

修改

代码：

#include <rapidjson/document.h>
#include <rapidjson/writer.h>
#include <rapidjson/stringbuffer.h>

void MyClass::myFunction()
{
    rapidjson::StringBuffer string;
    rapidjson::Writer<rapidjson::StringBuffer> jsonWriter(string);
}

以下是调试会话的链接： http://pastebin.com/a0FaQwf1

Answer 1

您永远不需要向用户提供头文件以运行程序。

你的图书馆可能只是提炼默认值， 这就是它在编译时丢失时不会失败的原因

Answer 2

对奇怪的移动/删除行为的解释可能是在移动期间共享对象仍然加载到内存中，并且在include目录中保留了打开的文件句柄。

你知道，在ext2 / 3/4下打开文件连接到inode而不是dir路径。因此，移动打开的文件不会有害。另一方面，IIRC也不会受到伤害。释放inode将被延迟，直到所有进程都关闭了文件。也许这只发生在你的mv和rm之间。