One of the catches of storing data in the source code (your Manifest.h and .cpp ) is a size limit for literal data, which depends on the compiler.
My suggestion is to use ld . It allows you to store arbitrary binary data in your ELF file (e.g. objcopy ). If you prefer to write your own solution, check out libbfd .
Say we have hello.cpp containing the usual C ++ example "Hello world". Now we have the following make file ( GNUmakefile ):
hello: hello.o hello.om $(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@ %.om: %.manifest ld -b binary -o $@ $< %.manifest: echo " $@ " > $@
What I'm doing here is to highlight the build phase, because I want the manifest (after converting to the ELF object format) to be associated with the binary. Since I use suffix rules, this is one way to go, others are certainly possible, including a better manifest naming scheme, where they also end up in .o files, and GNU make can figure out how to create them. Here I am talking about a recipe. Thus, we have .om files, which are manifests (arbitrary binary data) created from .manifest files. The recipe specifies the conversion of the binary input to an ELF object. The recipe for creating .manifest itself simply inserts a line into the file.
Obviously, the hard part of your business is not storing manifest data, but rather generating it. And frankly, I know too little about your build system to even try to suggest a recipe for the .manifest generation.
Whatever you choose in your .manifest file, there probably should be some kind of structured text that can be interpreted using the script you mention, or which can even be output by the binary itself if you implement the command line switch (and Ignore .so files and .so files cracked like regular executables when starting from the shell).
The above make file does not take into account dependencies - or rather, it will not help you create a list of dependencies in any way. You can probably get GNU to help you with this if you clearly express your dependencies for each purpose (i.e. static libraries, etc.). But do not waste this route ...
See also:
If you need specific names for the characters generated from the data (in your case, the manifest), you need to use a slightly different route and use the method described by John Ripley here .
How to access characters? Easy. Declare them as external (C linkage!) Data, and then use them:
#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); }
Characters are exact characters / bytes. You can also declare them as char[] , but this will lead to problems in the future. For instance. to call printf .
The reason I calculate the size myself is because.) I don’t know if the buffer will be guaranteed to be zero and b.) I did not find any documentation on the interaction with the *_size variable.
Side note: * in the format string tells printf that it should read the length of the string from the argument, and then select the next argument as the string to print. A.