Since MSVC does not support the macro method, I thought about just typing together a little ASM file to pull in the binaries. Thing is, I don't know assembly...

Could you provide me a basic example of an ASM file with which i can include binary files into the same object, just as if i had used the INCBIN macro?

Kind regards, Ingwie

Hi!

I've made an Adurino library based on your project.

It required a few changes to be made to incbin.h which I think improve versatility and may be of use. All change are non-breaking and backward-compatible and I tried to follow the original code style closely.

Explanation of every commit

bbc30009 - Add an option to specify different sections for data and its size

Arduino is based on AVR MCU, which has true harvard architecture. Its program memory cannot be directly read from the program, it requires special instructions. Due to this limitation it is very inconvenient to store the size of the included binary data in ROM. The size variable should be stored in RAM, hence it should be in different section. The commit adds an option to specify section for data size variable by defining INCBIN_SIZE_OUTPUT_SECTION macro. If undefined, it defaults to the value of INCBIN_OUTPUT_SECTION.

2e4c3222 - Add terminating NULL at the end of the data (optionallny)

When including text files, it is convenient to treat them as a c-string. The problem is that c-string should be NULL-terminated. This commit adds an option to add NULL byte at the end of the included data by defining INCBIN_APPEND_TERMINATING_NULL. Disabled by default.

Please check if I did ok there. I have a feeling this change may mess-up the alignment or something. I admit I don't fully understand the code here. For example, I don't understand why you append .byte 1 at the end of the data.

566be487 - Add an option to specify typename for data

Adds an option to specify the resulting pointer type of the included data. Just a convenience feature that removes the need of the cast every time you use the included data. Adds two new macros INCBIN_PTR_TYPE(NAME, FILENAME, DATA_PTR_TYPE) and INCBIN_EXTERN_PTR_TYPE(NAME, DATA_PTR_TYPE) with one additional argument alongside the existing.

The build error: https://travis-ci.org/andyli/incbin/builds/367773037

Undefined symbols for architecture x86_64:
  "_gLoremData", referenced from:
      _main in asserts.c.o
  "_gLoremEnd", referenced from:
      _main in asserts.c.o
  "_gLoremSize", referenced from:
      _main in asserts.c.o
  "_gOnebyteData", referenced from:
      _main in asserts.c.o
  "_gOnebyteEnd", referenced from:
      _main in asserts.c.o
  "_gOnebyteSize", referenced from:
      _main in asserts.c.o
  "_gSevenbytesData", referenced from:
      _main in asserts.c.o
  "_gSevenbytesEnd", referenced from:
      _main in asserts.c.o
  "_gSevenbytesSize", referenced from:
      _main in asserts.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [asserts] Error 1
make[1]: *** [CMakeFiles/asserts.dir/all] Error 2
make: *** [all] Error 2

My test code can be seen at https://github.com/andyli/incbin/commit/47c3b76c833c9d40d13d1dbf84274638db9d6911

Notice that the test passed in the Linux builds.

Thanks for INCBIN! Before I found your tool I was trying to do this method myself, and was struggling to get it to link while cross-compiling. I am hopefull that this tool will also make it easier for me to make mac builds when the time comes.

When I used the latest incbin.h, I got this error when cross-compiling using the MXE cross compile on a linux host:

$ /home/jasonwoof/software/mxe/usr/bin/i686-w64-mingw32.static-gcc -c -o test.o test.c
/tmp/cca2SpPv.s: Assembler messages:
/tmp/cca2SpPv.s:5: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/cca2SpPv.s:5: Error: junk at end of line, first unrecognized character is `b'
/tmp/cca2SpPv.s:10: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/cca2SpPv.s:10: Error: junk at end of line, first unrecognized character is `b'
/tmp/cca2SpPv.s:15: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/cca2SpPv.s:15: Error: junk at end of line, first unrecognized character is `b'
zsh: exit 1     /home/jasonwoof/software/mxe/usr/bin/i686-w64-mingw32.static-gcc -c -o test.o

$ cat test.c
#include <stdio.h>
#define INCBIN_STYLE INCBIN_STYLE_SNAKE
#define INCBIN_PREFIX binary_
#include "incbin.h"
INCBIN(game_js, "game.js");

int
main(int argc, char **argv) {
    printf("%s, %0d\n",
        binary_game_js_data,
        binary_game_js_size
    );
    return 0;
}

As a workaround, I commented out the .type asm directive like this:

/* It's safe to use `@' on other architectures */
#    define INCBIN_TYPE(NAME)    "#.type " INCBIN_STRINGIZE(INCBIN_PREFIX) #NAME ", @object\n"

Then my test compiles and runs perfectly (built on linux, tested with wine) and also compiles and runs fine an/for native linux.

The one flaw in this otherwise perfect-for-the-job tool is that an INCBIN()ed binary doesn't get included in the gcc auto-dependency-file-generation of " -MMD -MP -MF"". I wonder if there is some kind of way to fake out gcc/g++ to emit a dependency on the binary file?

Hi, I've checked if this would work using the emscripten compiler. I try to compile the test program.

<inline asm>:1:17: error: Expected ,, instead got: 
.section .rodata

<inline asm>:16:6: error: symbol 'gLoremData': unsupported subtraction expression used in relocation.
.int gLoremEnd - gLoremData

I've no doubt the section statement can be fixed, by examing some -S output from the compiler. Regarding the second, I don't have any ideas.

I just tried to compile incbin.c on my 32bit Win7 maschine and it went berserk about missing semicolons and such. Weirdly, renaming the file to incbin.cpp (tricking cl into C++ mode) fixed the issue. Would be nice if you could look into this.

(full background, with some overhead, at https://github.com/PowerDNS/pdns/issues/9835#issuecomment-741748081)

We have this piece of code:

INCBIN(api_swagger_yaml, "api-swagger.yaml");
static const string g_api_swagger_yaml{(const char*)gapi_swagger_yamlData, gapi_swagger_yamlSize};
INCBIN(api_swagger_json, "api-swagger.json");
static const string g_api_swagger_json{(const char*)gapi_swagger_jsonData, gapi_swagger_jsonSize};

When we compile this with gcc's or clang's Address Sanitizer, it crashes in a string constructor.

Reordering the code like this fixes the problem:

INCBIN(api_swagger_yaml, "api-swagger.yaml");
INCBIN(api_swagger_json, "api-swagger.json");
static const string g_api_swagger_yaml{(const char*)gapi_swagger_yamlData, gapi_swagger_yamlSize};
static const string g_api_swagger_json{(const char*)gapi_swagger_jsonData, gapi_swagger_jsonSize};

A copy/paste of my understanding of the reason, from the linked ticket:

• INCBIN sets .section rodata
• the compiler sets .bss for storing the const string
• the next INCBIN call sets .section rodata again
• the compiler omits .bss for the second const string - presumably because it assumes it is already in BSS

Now the question is - can we add something to the macro to 'restore' the previously active section, or inform the compiler that it needs to repeat its section choice?

Just after you fixed the incbin tool problem, I updated and re-compiled my source using the script - the tool itself works again, thanks for that :).

But now I have a more awkward problem:

src/IceTea.cpp:154:29: error: use of undeclared identifier 'gSTDData'
        {"std.os",          INCBIN_DATA(STD),           INCBIN_LEN(STD)},
                            ^
src/IceTea.cpp:20:27: note: expanded from macro 'INCBIN_DATA'
#define INCBIN_DATA(name) g ## name ## Data
                          ^
<scratch space>:356:1: note: expanded from here
gSTDData
^

I was so confused that it took me a while untill I actually realized how I could best test this. I took the file containing the INCBIN statements and wrote a teensy tiny C++ program:

#include "scripts.rc"
int main() {
  return 0;
}

Nothing special going on - except script.rc, which is the header in which I have my incbin statements. the .rc is probably misleading, but it makes me think of resource container. So that works for me - besides, it has worked for a logn time now :).

After compiling this tiny program, I inspected the symbol table...and:

[email protected] ~/W/IceTea $ nm t
0000000100000000 T __mh_execute_header
00000001000014f0 s _gConfigurable0_0_DATA
00000001000015a8 s _gConfigurable0_0_END
00000001000015b0 s _gConfigurable0_0_SIZE
000000010000a860 s _gInternalBootstrapIt0_0_DATA
000000010000d0ee s _gInternalBootstrapIt0_0_END
000000010000d0f0 s _gInternalBootstrapIt0_0_SIZE
0000000100001000 s _gSTD0_0_DATA
00000001000014de s _gSTD0_0_END
00000001000014e0 s _gSTD0_0_SIZE
00000001000015c0 s _glibIceTea0_0_DATA
000000010000a84b s _glibIceTea0_0_END
000000010000a850 s _glibIceTea0_0_SIZE
0000000100000f90 T _main
                 U dyld_stub_binder

0_0_DATA and such! Now, that does explain why my tiny helper macro did no longer work. :)

Looking into incbin.h, this also does not seem to be the intended behavior either. Could you look into this please? This basically broke my app for now. ^^"

OK, now that I've looked down into the tests, which take the address of the end symbol, I know how to use it: https://github.com/graphitemaster/incbin/blob/6a3ca1590754679bf9155ac00cbf9259a87ac412/test/asserts.c#L12-L18

I didn't find anywhere in the docs that show an example usage. What they do say implies that the symbol is already a const unsigned char*, when it's actually a const unsigned char immediately after the data, of which you must take the address. https://github.com/graphitemaster/incbin/blob/6a3ca1590754679bf9155ac00cbf9259a87ac412/incbin.h#L270-L288

Bitcode is an Apple technology that basically allows Apple to recompile apps submitted to the App Store at will for optimization reasons.

https://developer.apple.com/documentation/xcode/reducing_your_app_s_size/doing_basic_optimization_to_reduce_your_app_s_size

One of the limitations of this technology is that the app must be 100% buildable from the bitcode embedded into the binary, which I assume is in fact the LLVM IR. This apparently disallows any sort of architecture-specific assembly in the source code.

As a result, when trying to upload an app with bitcode enabled, ITMS returns this error:

ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary because it includes assembly source code or inline assembly. To resolve this issue, rewrite the corresponding code in a higher-level language such as Objective-C or Swift and redeliver your app.

While looking for a workaround, I found that Xcode allows one to add LLVM assembly sources to a project. I wasn't able to find a directive equivalent to .incbin in the LLVM assembly manual, though, but maybe I simply missed it.

Anyway, the workaround, of course, is to recode any binaries into C-array literal syntax and compile them as C code.

I suggest that this issue be mentioned in the README. It would also be helpful if the library emits a warning if targeting the iOS platform.

I compiled the incbin.c file and made an executable if I run it with help I get:

 ./a.exe phong_lighting.glsl  -I../../Src/Engine/EmbeddedShaders/ -o ../../buildvs/data.c  -help
C:\Users\Makogan\Documents\neverengine\libraries\incbin\a.exe [-help] [-Ipath...] | <sourcefiles> | [-o output] | [-p prefix]
   -o         - output file [default is "data.c"]
   -p         - specify a prefix for symbol names (default is "g")
   -S<style>  - specify a style for symbol generation (default is "camelcase")
   -I<path>   - specify an include path for the tool to use
   -help      - this
example:
   C:\Users\Makogan\Documents\neverengine\libraries\incbin\a.exe source.c other_source.cpp -o file.c
styles (for -S):
   camelcase
   snakecase

If I try to run it normally (without the help flag) this is the data.c file that gets generated:

/* File automatically generated by incbin */
#include "incbin.h"

#ifdef __cplusplus
extern "C" {
#endif


#ifdef __cplusplus
}
#endif

No errors or warnings are thrown by the tool.

I am on windows 10

Although one could simply add incbin to the version control of an application as it is quite small, this has the caveat that you cannot tell automatically if a new version is available. Being able to use conan to download and install the project would facilitate integrating the tool in projects.

Hello,

in my Python compiler Nuitka, I am generating extension modules, and will now start using incbin after previously working with linker options to include stuff directly, but LTO came in the way of that. And then I found your brilliant tool to solve the issue in a way more portable fashion. And it's working very nicely.

However, what I discovered is that the symbols are exported, and what happens is when I load two extension modules, is that they get confused with their read only symbols matching, and then only one gets loaded and the other used wrongly. I have added CRC32 checking, and it fails if the second module is loaded, where otherwise in all of Nuitka this doesn't happen.

I am aware that I can make the symbol names not match, by prefixing randomly, but since the users don't cooperate, I would e.g. have to use the hash. Alternatively I think a linker script might prevent the export of the symbols.

In my use in Nuitka, I only need the data locally, I do not need it to be visible to outside code, i.e. I would be fine if the symbol was static in the C sense, and I was wondering if there was a way to just make it local through incbin. Checking out the assembler man page revealed that there is no such thing as a local symbol for it (of course?). So I tried to empty the declaration of INCBIN_GLOBAL and this results in the symbols not being exported and that seems to work, so I am now having a INCBIN_LOCAL that guards this, and it seems to work, at least the binary extension modules doesn't export the symbols anymore, yet the data seems accessible by the code in the same unit.

I guess, that might make sense to add it as a feature to incbin? I would make a PR with the basic change if you agree.

When I used INCBIN with CMake I have an error like this:

  "C:\Users\UserName\AppData\Local\Temp\ccgFslxv.s: Assembler messages:"
  "C:\Users\UserName\AppData\Local\Temp\ccgFslxv.s:2549: Error: file not found: FileName.txt" .

This happens because the compiler cannot find the file in the build directory. With this macro you can automatically copy used files with a template [filename].incbin.[file extension] from directory [input_dir_absolute_path] to directory [output_dir_absolute_path]. Сopied files will looks like [filename].[file extension]. Usage:

1. move_incbin_to_destination([input_dir_absolute_path] [output_dir_absolute_path]) This copy files from [input_dir_absolute_path] to [output_dir_absolute_path] and remove ".incbin" from them names.
2. move_incbin_to_destination([input_dir_absolute_path] [output_dir_absolute_path] RECURSE) This copy files from [input_dir_absolute_path]/[recursive all child folders] to [output_dir_absolute_path]/[recursive all child folders from input dir] and remove ".incbin" from them names. Typical usage is (including quotes): move_incbin_to_destination( "${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_BINARY_DIR}" RECURSE) You can find examples in folder "test".