Yes, but it's linker-specific and non-portable. It can also come with some annoying limitations, like having to separately provide the data size of each symbol. In some cases this might be introspectable, but again comes at the expense of portability.

ELF-based variants of the IAR toolchain, for example, provide a means of directly embedding a file as an ELF symbol, but without the size information being directly accessible.

GNU ld and LLVM lld do not provide any embedding functionality at all (as far as I can see). You would have to generate a custom object file with some generated C or ASM encoding the binary content.

MSVC link.exe doesn't support this either, but there is the "resource compiler" to embed binary bits and link them in so they can be retrieved at runtime.

Having a universal and portable mechanism which works everywhere will be a great benefit. I'll be using it for compiled or text shaders, compiled or text lua scripts, small graphics, fonts and all sorts.

The article address this directly. If you're only targeting one platform then this is reasonably easy (albeit still not as easy as #embed), but if you need to be portable then it becomes a nightmare of multiple proprietary methods.

You probably don't realize that not every system is using ELF binaries....

Sure, but to add binary data to any executable on any platform is more involved.

As an example, see [1]. That will turn any file into a C file with a C array, and I use it to embed a math library ([2]) into the executable so that the executable does not have to depend on an external file.

[1]: https://git.yzena.com/gavin/bc/src/branch/master/gen/strgen....

[2]: https://git.yzena.com/gavin/bc/src/branch/master/gen/lib.bc

Then you don’t get regular optimizations like deduping identical declarations.

Or source line location debug info, though nobody tries to show that for data at the moment.

The less you have to mess with linker scripts, the better.