0

在构建共享对象时，我忘记将第 3 方“仅标头”库标头 (.h) 文件放入正确的路径中。它建造得很好——回顾起来令人惊讶。

在我的共享对象中使用该第 3 方库时，在运行时恰好发生了段错误。

我不明白的部分是当我将这些头文件复制到用 指定的路径时#include，我无法导致段错误。我什至没有重新构建对象。非常奇怪的是，当我 mv 头文件所在的目录时，它仍然有效 - 没有段错误。但是，当我完全 rm 目录时，它崩溃了。它是否查找当前目录和子目录的头文件？我在标准中也有那个只有标题的库（？）/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

4

2 回答 2

0

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

您的库可能只是优化了默认值，这就是为什么它在编译时丢失时不会失败的原因

于 2012-04-12T10:09:39.980 回答
0

对奇怪的移动/删除行为的解释可能是共享对象在移动过程中仍被加载到内存中，并保留了包含目录中某些内容的打开文件句柄。

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

于 2012-04-12T10:35:52.377 回答