0

共有オブジェクトを構築するときに、サードパーティの「ヘッダーのみ」のライブラリ ヘッダー (.h) ファイルを正しいパスに配置するのを忘れていました。それはうまく構築されました-振り返ってみると驚くべきことです。

実行すると、そのサードパーティのライブラリが共有オブジェクトで使用された行で正確にセグメンテーション違反が発生しました。

わからない部分は、それらのヘッダーファイルを で指定したパスにコピーした#includeところ、セグメンテーションフォールトを起こすことができませんでした。オブジェクトを再構築することさえしませんでした。非常に奇妙なことは、ヘッダーファイルがあるディレクトリを移動しても、まだ機能していることです-セグメンテーション違反はありません。ただし、ディレクトリを完全に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 に接続されています。したがって、開いているファイルを移動しても害はありません。一方、IIRC も削除しても害はありません。すべてのプロセスがファイルを閉じるまで、inode の解放は延期されます。多分これはあなたのmvとrmの間で起こった.

于 2012-04-12T10:35:52.377 に答える