В стеке и в других местах было несколько публикаций, описывающих, как встраивать двоичные двоичные объекты в двоичные файлы эльфов.
Встраивание двоичных двоичных объектов с использованием gcc mingw
и
C / C ++ с GCC: Статически добавлять файлы ресурсов в исполняемый файл / библиотеку
является наиболее полным ответом.
Но есть возможная проблема, о которой никто не упоминает. Вот быстрый foo.txt, прикрытый к foo.o:
$ objdump -x foo.o
foo.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 0000000d 00000000 00000000 00000034 2**0
CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
00000000 l d .data 00000000 .data
0000000d g .data 00000000 _binary_foo_txt_end
0000000d g *ABS* 00000000 _binary_foo_txt_size
00000000 g .data 00000000 _binary_foo_txt_start
Так вот, я на самом деле не хожу на все эти выводы - есть ли документация для этого материала ??? Я думаю, что большинство из них достаточно очевидно, «g» является глобальным, а «l» локальным и т. Д.
Что выделяет выравнивание для сегмента .data, установленного на 0. Означает ли это, что я думаю, что это значит? То есть: когда дело доходит до линковки, компоновщик будет идти "ах да, где угодно ..."
Если вы встраиваете данные char или работаете на x86, вы никогда этого не заметите. Но если вы встраиваете int-данные или, как я делаю, 16- и 32-битные данные в ARM, вы можете получить ловушку выравнивания в любой точке.
Мое внутреннее чувство заключается в том, что это означает, что либо objcopy требуется другая опция для указания выравнивания двоичного двоичного объекта, либо он не работает, и вы не должны использовать этот метод вообще.