ソース コード ( yourManifest.hおよび.cpp) にデータを格納する際の問題点の 1 つは、コンパイラに依存するリテラル データのサイズ制限です。
私の提案は、を使用することldです。これにより、任意のバイナリ データを ELF ファイルに保存できます (そうですobjcopy)。独自のソリューションを作成する場合は、 をご覧くださいlibbfd。
hello.cpp通常の C++ の「Hello world」の例が含まれているとします。これで、次のメイク ファイル ( GNUmakefile)が作成されました。
hello: hello.o hello.om
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@
%.om: %.manifest
ld -b binary -o $@ $<
%.manifest:
echo "$@" > $@
ここで行っているのは、マニフェスト (ELF オブジェクト形式への変換後) もバイナリにリンクする必要があるため、リンク段階を分離することです。私は接尾辞規則を使用しているので、これは 1 つの方法ですが、他の方法も確かに可能です。たとえば、マニフェストが最終的に.oファイルになり、GNU make がそれらを作成する方法を理解できる、マニフェストのより良い命名スキームが含まれます。ここでは、レシピについて明示しています。つまり、ファイル.omから作成されたマニフェスト (任意のバイナリ データ) である.manifestファイルがあります。レシピには、バイナリ入力を ELF オブジェクトに変換することが記載されています。それ自体を作成するためのレシピは、.manifest単純に文字列をファイルにパイプします。
明らかに、あなたの場合のトリッキーな部分は、マニフェスト データを保存することではなく、生成することです。率直に言って、私はあなたのビルド システムについてほとんど知りません.manifest。
ファイルに投げ込むもの.manifestは、おそらく、あなたが言及したスクリプトによって解釈できる、またはコマンドラインスイッチを実装する場合はバイナリ自体によって出力される可能性のある構造化テキストである必要があります（通常の実行可能ファイルのように動作するようにハッキングされた.soファイルやファイルは無視してください）.soシェルから実行する場合)。
上記の make ファイルは依存関係を考慮していません。つまり、依存関係リストを作成するのにまったく役立ちません。各目標 (つまり、静的ライブラリなど) に対する依存関係を明確に表現すれば、おそらく GNU make を強制してそれを支援させることができます。しかし、そのルートを取る価値はないかもしれません...
また見てください：
データ (あなたの場合はマニフェスト) から生成されたシンボルに特定の名前が必要な場合は、少し異なるルートを使用し、John Ripley が説明した方法を使用する必要があります。
シンボルにアクセスするには？簡単。それらを外部 (C リンケージ!) データとして宣言してから使用します。
#include <cstdio>
extern "C" char _binary_hello_manifest_start;
extern "C" char _binary_hello_manifest_end;
int main(int argc, char** argv)
{
const ptrdiff_t len = &_binary_hello_manifest_end - &_binary_hello_manifest_start;
printf("Hello world: %*s\n", (int)len, &_binary_hello_manifest_start);
}
記号は正確な文字/バイトです。として宣言することもできますが、後でchar[]問題が発生する可能性があります。たとえば、printf通話の場合。
私が自分でサイズを計算している理由は、a.) バッファーがゼロで終了することが保証されているかどうかわからない、および b.)*_size変数とのインターフェースに関するドキュメントが見つからなかったからです。
補足:*フォーマット文字列の はprintf、引数から文字列の長さを読み取り、出力する文字列として次の引数を選択する必要があることを示しています。