NENeywiny·Dec 26, 2025
I use https://github.com/graphitemaster/incbin . It mostly works (had to make some mods when I needed more section magic to happen). Nothing I'm on supports #embed yet but here's to hoping.
In C/C++ Embedded Files (2013)graphitemaster
incbin
C2017–2025
graphitemaster / incbin
incbin
Include binary files in C/C++
8Distinct people
8Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
Include binary files in C/C++
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2017-05-10 12:39:24 UTC to 2025-12-26 23:10:43 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
8 sourcesOK, yes, that does work. You can totally put application specific stuff in the elf and reflect on it at runtime. Much easier is to point a symbol value at the start of the data in the elf and refer to that symbol, then you don't have to crawl the headers yourself. The linker does it for you.
See https://github.com/graphitemaster/incbin for a pretty wrapper around that.
Aside from there being a drastically simpler answer to this problem available in sketchily documented fashion (the asm guys know .incbin is a thing, but higher level languages overcomplicate it), it's a good post. Idea is sound and goal was achieved.
ELF linkers will create symbols pointing to sections with C identifiers as names too if you want to do that instead of inline asm. Without linker scripts I mean, they just do that out of the box.
In Self-contained Linux applications with lone LispThanks for the link. We also make static websites by direct inclusion their HTML code in the C++ binary of ClickHouse.
I've tried to use this library but found a bug: https://github.com/graphitemaster/incbin/issues/61
In The theory versus the practice of “static websites”Tangentially, I've been exploring something kind of fascinating...
So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable.
For example, for C or C++
https://github.com/graphitemaster/incbin
So here's the interesting part - we decided to build executables in a way that data in those executables could not be changed (makes sense since it's compiled and the compiled code runs on the machine, and for security reasons).
That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.
So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except i
Read the rest
t can change.
Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage.
What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.
Just a musing but tangentially related to your "baked data" - basically, embedded resources in executables just embeds the encoded data right into an executable.
For scripting languages, of course, we can just make a script file that contains a variable with the encoded data as base64 directly.
For the latter 2, it's only good for relatively small static data of course, but it would be interesting to build tech that somehow lifted that constraint of executables.
Sure, but only if the text file looks like a C string literal, i.e. starts and ends with double quotes (which would make it into a weird text file).
Doing
const char *s = "
#inclued "test.txt"
";
won't work, since the preprocessor won't interpret directives inside string literals of course.
In many assemblers, there is a directive called "incbin" which pastes in unstructured binary data at the point of usage. I just found a very clever C and C++ wrapper [1] for that, which gives you an INCBIN() macro. Nice!
[1]: https://github.com/graphitemaster/incbin
In Olive.c: a simple graphics library that does not have any dependenciesHaven't the people making the standards other things to do, like, integrating useful features instead of duplicating incbin.h [0] years after that feature worked?
https://github.com/graphitemaster/incbin/blob/main/incbin.h
In Embed is in C23I have been using a library named incbin (https://github.com/graphitemaster/incbin).
On Mac and Linux it doesn't even require a cli tool to convert the file. It just embed the content using the `.incbin` directive of the inline assembler.
It is pretty perfect for my project, which is a deep learning application for Android. I use it to embed the CNN model file into the C++ code. It let me avoid putting it in the apk, and then loading it from Java, and then passing it to C++.
In Embedding files in C programs with koioThere is also an option to use assembler or inline asm. I found quite a nice utility that uses inline asm [0]. It's widely portable and I think that I will use it instead of my naive asm/shell combo that doesn't work with mingw asm.
The problem with objcopy outside of unconvenient usage and naming is that naive objcopy will result in your binary having executable stack [1]. You can change a symbol name, but that's also unconvenient.
Check resulting binary with:
$ readelf -lW the_binary | grep GNU_STACK
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8
$
Notice: RWE instead RW.
Also: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#H...
[0] https://github.com/graphitemaster/incbin
[1] https://news.ycombinator.com/item?id=10816322#10818085
EDIT:
My shell script - bin2o.sh:
#!/bin/s
Read the rest
h
set -e
filename="$1"
name=$(echo "$1" | sed "s/[^A-Za-z0-9]/_/g")
obj="$2"
echo \
" .section .rodata
.global ${name}
.type ${name}, @object
.global ${name}_size
${name}:
.incbin \"${filename}\"
1:
${name}_size:
.int 1b - ${name}
.section .note.GNU-stack,\"\",%progbits
" | gcc -x assembler -c - -o "$obj"