Gcc файл ресурсов linux

Использование файла ресурсов (.rc) при сборке проектов в Linux

21 Декабря 2011

Не буду рассказывать про то, что такое файл ресурсов, для чего нужен, и как его подключить к проекту (кто не в курсе этих вопросов – дальше можно читать только для общего образования), а сразу опишу проблему. Предположим, у нас есть файл, скажем, resources.rc, в котором содержится все необходимое проекту добро и успешно используется под Windows с помощью нехитрого набора функций LoadResource, FindResource и т.п. Задача: собрать этот же проект под Linux, в процессе подключить ресурсы к исполняемому файлу и, естественно, прочитать их в своей программе.

При сборке проекта в Windows файл определения ресурсов (.rc) компилируется в двоичный вид (.res) и на этапе компоновки подключается к exe-файлу, фактически прописываясь после запуска где-то в оперативной памяти. Напомню, что определить местоположение искомого ресурса позволяет функция:

Технология отлажена, сомнению не подвергается. Уже на этом этапе в Linux возникает несколько вопросов. Во-первых, чем откомпилировать исходный файл ресурсов в двоичный формат? Во-вторых, как подключить его к формируемому исполняемому файлу проекта? И, в-третьих, как найти и прочитать в файле нужный ресурс?

Шаг 1. Компилируем файл ресурсов

Самый простой шаг. С данной задачей вполне справляется утилита wrc (Wine Resource Compiler), которая умеет компилировать файл ресурсов в 16- или 32-разрядный двоичный формат. Применение простое:

Шаг 2. Подключение файла ресурсов

У нас уже имеется скомпилированный файл ресурсов, представленный в двоичном виде, однако, как это ни странно, пока что он представляет собой всего лишь набор символов. В таком виде его даже можно будет включить в сборку, но найти его в памяти во время работы программы будет проблематично, и наши ресурсы так и останутся болтаться внутри бинарника космическим мусором. На помощь приходит утилита objcopy, которая умеет преобразовывать объектные (и исполняемые) файлы в разные «правильные» форматы, которые потом уже можно будет прилинковать. С ее помощью преобразуем наш двоичный файл ресурсов (resources.res) в объектный (resources.o). Включаем магию:

Говорим, что на входе у нас двоичный файл (-I binary), на выходе хотим получить файл в формате объектных файлов на 32-разрядной платформе x86 (-O elf32-i386), причем он должен выглядеть как «исполняемый» файл (-B i386). В таком виде его уже можно будет подключать к проекту:

Я использую cmake, поэтому в мой CMakeLists.txt добавил несколько строчек:

На этом почти вся магия кончается. Остается невыясненным только один вопрос: как найти ресурсы в готовом executable файле? Компоновщик, выполнив свою работу, великодушно оставил в собранном файле несколько меток:

По этим меткам теперь можно прочитать содержимое файла ресурсов.

Шаг 3. Поиск и чтение ресурсов в программе

Для начала определим переменные, соответствующие вышеописанным меткам компоновщика:

При определении использую тип char, поскольку в моем проекте в ресурсах хранятся только ссылки на текстовые файлы в формате xml. Дополнительно определю привычные типы, не известные Linux, исключительно для удобства работы

Для применения FindResource не хватает только hModule. Под Windows в эту переменную будет записан хендл текущего модуля, в Linux – адрес начала блока ресурсов в нашем файле

Все готово для поиска нужного ресурса, кроме того, что в Linux отсутствует соответствующая функция, которую придется изготовить самостоятельно. Поскольку все ресурсы, которые были подключены к нашему проекту, сохранены в формате файла res, неплохо было бы для начала узнать его формат. Читаем в MSDN, что в основе формата лежит структура RESOURCEHEADER

Под Linux я также переопределил типы

и добавил константу, обозначающую тип ресурса: в моем случае это простые данные

Итак, в файле ресурсов после структуры RESOURCEHEADER следуют данные, размер которых составляет DataSize байт. Этой информации почти достаточно для того, чтобы распотрошить его полностью. Последняя засада, которая поджидает на пути к цели: каждый ресурс, включающий структуру и сами данные, выровнен по двойному слову. То есть, в случае если его размер в байтах не кратен четырем, в хвост к нему дописывается недостающее количество нулевых символов. У меня получилась такая функция для поиска ресурса типа RC_DATA по заданному имени

Теперь функция FindResource вернет нам адрес начала искомого ресурса, который будем использовать далее

И более ничто не мешает прочитать содержимое памяти в свою переменную

Resource::

Безусловно, рассмотренный пример использования в Linux привычных для Windows файлов определения ресурсов довольно примитивен, поскольку «заточен» только под один тип данных (RT_RCDATA). Однако вполне представляет собой основу детской пирамидки с уже одетым на нее небольшим колечком, поверх которого можно набросать еще много всего.

Источник

GNU Compiler Collection, первые шаги

Эта заметка призвана на простых примерах познакомить начинающего nix-разработчика с инструментами GNU, в частности с компилятором GCC.

С его помощью мы и создадим простейшую программу. По большому счету все, как обычно. Заводим специальную папку, в которой будет размещаться проект.
Создаем в ней файл с именем: hello.c
Открываем файл в любом текстовом редакторе и пишем простейший код:

#include
int main(void)
<
printf(«Hello world!»);
return(0);
>

Сохраняем файл и выполняем команду: gcc hello.c

В созданной нами папке появился новый файл — a.out, это название присваивается по умолчанию, если специально не задано другого.

Это и есть исполняемый файл. Попробуем его запустить, для этого в консоли набираем: ./a.out

И радуемся в связи с первой написанной программой в линуксе!

Идем далее. При запуске исполняемого файла, если мы укажем только его название, система будет искать его в каталогах /usr/bin и /usr/local/bin, и, естественно, не найдет. Первый из них предназначен для размещения стабильных версий программ, как правило, входящих в дистрибутив Linux. Второй – для программ, устанавливаемых самим пользователем (за стабильность которых никто не ручается). По умолчанию, при сборке программы, устанавливаются в каталог /usr/local/bin.

Флаги используемые при компиляции

Флаг -o используем чтобы указать определенное имя получаемому исполняемому файлу: gcc hello.c -o say_hello

Флаг -E используем чтобы посмотреть, что получается после работы препроцессора. Этот флаг останавливает выполнение программы, как раз на этапе обработки препроцессором. В результате получается файл исходного кода с включённым в него содержимым заголовочных файлов.
Выподняем/смотрим: gcc -E hello.c -o hello.cpp

Флаг -с используем для создания объектных файлов (аналог *.obj): gcc -c kalkul.c

Название получаемого файла такое же, но компилятор изменяет расширение .c на .o (но указать можно и вручную).

Флаг -x используем, если создаётся объектный файл из исходника, уже обработанного препроцессором (например такого, какой мы получили выше), мы должны обязательно указать явно, что компилируемый файл является файлом исходного кода, обработанный препроцессором, и имеющий теги препроцессора. В противном случае он будет обрабатываться, как обычный файл C++, без учёта тегов препроцессора, а значит связь с объявленными функциями не будет устанавливаться.

Файл C++, обработанный препроцессором обозначается cpp-output:
gcc -x cpp-output -c hello.cpp

Собирается проект следующим образом: gcc hello.o -o say_hello
Запускаем: ./say_hello

Для чего нужна вся эта возня с промежуточными этапами?
Программы редко состоят из одного файла. Как правило исходных файлов несколько, и они объединены в проект. И в некоторых исключительных случаях программу приходится компоновать из нескольких частей, написанных, возможно, на разных языках. В этом случае приходится запускать компиляторы разных языков, чтобы каждый получил объектный файл из своего исходника, а затем уже эти полученные объектные файлы компоновать в исполняемую программу.

Источник

C/C++. Как использовать внедряемые ресурсы приложения, при работе в GCC на Linux

Захотелось как-то мне использовать в Linux внедряемые ресурсы, причём, автоматически. В общем, задача такая:

1. Имеется Eclipse проект программы на C++.
2. ОС: Linux Ubuntu. Компилятор: G++
3. В проекте используются данные из внешних файлов: строки локализации, SQL-запросы, картинки, звуки и т.д.
4. Все ресурсы необходимо внедрить в исполняемый файл, ибо программу планируется распространять, как портативную.
5. Кроме того, хочется, что бы процесс был максимально автоматизирован, ибо лень.

Для начала, поиск по форумам дал несколько возможных способов решения задачи. Среди найденных наиболее универсальным мне показалась идея использовать параметр « —format=binary » линковщика « ld ». Посты на форумах обещали, что команда вида:

прилинкует к приложению файл «my.res» и создаст два символа — _binary_my_res_start и _binary_my_res_end , указывающих, соответственно, на начало и конец тех самых данных, которые были в прилинкованном файле. Следовательно, обращение к данным из C++ можно было бы осуществить как-то так:

Но не тут-то было. Пишем всё, как надо, а компилятор недоволен. Символа «_binary_my_res_start» , видите ли, он найти не может. Ну ничего, nm нам в помощь. Пишем следующую команду:

Выходит, что имя символа включает в себя весь путь до него, что, в перспективе, может привести к необходимости постоянного переписывания заголовочного файла, содержащего ссылки на ресурсы. Проблема решается, если в событие PostBuild в настройках проекта Eclipse добавить вызов следующего скрипта:

Хорошо. Теперь заголовочный файл будет каждый раз как новенький, а обращаться к данным можно по именам переменных, которые не будут меняться, если только не переименовать сам ресурсный файл. Кроме того, данный скрипт вычисляет размер для каждого ресурса. Не то что бы отнять от указателя на конец указатель на начало было большой проблемой, но, всё же, так удобнее.

Но это, пока что, не всё. Ведь добавление каждого нового ресурса в проект будет превращаться в форменный АД. И эту проблему также можно решить при помощи скрипта, только уже на этапе линковки:

Источник

C/C++. Как использовать внедряемые ресурсы приложения, при работе в GCC на Linux

Захотелось как-то мне использовать в Linux внедряемые ресурсы, причём, автоматически. В общем, задача такая:

1. Имеется Eclipse проект программы на C++.
2. ОС: Linux Ubuntu. Компилятор: G++
3. В проекте используются данные из внешних файлов: строки локализации, SQL-запросы, картинки, звуки и т.д.
4. Все ресурсы необходимо внедрить в исполняемый файл, ибо программу планируется распространять, как портативную.
5. Кроме того, хочется, что бы процесс был максимально автоматизирован, ибо лень.

Для начала, поиск по форумам дал несколько возможных способов решения задачи. Среди найденных наиболее универсальным мне показалась идея использовать параметр « —format=binary » линковщика « ld ». Посты на форумах обещали, что команда вида

прилинкует к приложению файл «my.res» и создаст два символа — _binary_my_res_start и _binary_my_res_end , указывающих, соответственно, на начало и конец тех самых данных, которые были в прилинкованном файле. Следовательно, обращение к данным из C++ можно было бы осуществить как-то так:

Но не тут-то было. Пишем всё, как надо, а компилятор недоволен. Символа «_binary_my_res_start» , видите ли, он найти не может. Ну ничего, nm нам в помощь. Пишем следующую команду:

Выходит, что имя символа включает в себя весь путь до него, что, в перспективе, может привести к необходимости постоянного переписывания заголовочного файла, содержащего ссылки на ресурсы. Проблема решается, если в событие PostBuild в настройках проекта Eclipse добавить вызов следующего скрипта:

Хорошо. Теперь заголовочный файл будет каждый раз как новенький, а обращаться к данным можно по именам переменных, которые не будут меняться, если только не переименовать сам ресурсный файл. Кроме того, данный скрипт вычисляет размер для каждого ресурса. Не то что бы отнять от указателя на конец указатель на начало было большой проблемой, но, всё же, так удобнее.

Но это, пока что, не всё. Ведь добавление каждого нового ресурса в проект будет превращаться в форменный АД. И эту проблему также можно решить при помощи скрипта, только уже на этапе линковки:

Отлично. Теперь все файлы, которые лежат в подкаталоге «res», будут сами попадать в ресурсы при каждой сборке.

Источник

C / C++ с GCC: статическое добавление файлов ресурсов в исполняемый файл / библиотеку

есть ли у кого-нибудь идея, как статически скомпилировать любой файл ресурсов прямо в исполняемый файл или файл общей библиотеки с помощью GCC?

например, я хотел бы добавить файлы изображений, которые никогда не меняются (и если они это сделают, мне все равно придется заменить файл) и не хотел бы, чтобы они лежали в файловой системе.

Если это возможно (и я думаю, что это потому, что Visual C++ для Windows может сделать это тоже), как я могу загрузить файлы, которые хранятся в собственном двоичном файле? Выполняет ли исполняемый файл синтаксический анализ, находит файл и извлекает из него данные?

возможно, есть вариант для GCC, который я еще не видел. Использование поисковых систем на самом деле не выплюнуло правильный материал.

Мне нужно, чтобы это работало для общих библиотек и обычных исполняемых файлов ELF.

любая помощь приветствуется

8 ответов

дает что-то типа:

для совместимости с другим кодом, то вы можете использовать либо fmemopen чтобы получить «обычный»

обновление Я вырос, чтобы предпочесть контроль собрание Джона Рипли .incbin на основании решения предлагает и теперь использует вариант на этом.

я использовал objcopy (GNU binutils) для связи двоичных данных из файла foo-data.bin в раздел данных исполняемого файла:

это дает вам foo-data.o объектный файл, который вы можете связать с исполняемым файлом. Интерфейс C выглядит примерно как

так что вы можете делать такие вещи, как

если ваша целевая архитектура имеет специальные ограничения относительно того, где хранятся постоянные и переменные данные, или вы хотите сохранить эти данные в .text сегмент, чтобы он вписывался в тот же тип памяти, что и ваш программный код, вы можете играть с objcopy параметры немного больше.

вы можете вставить двоичные файлы в исполняемый файл с помощью ld линкер. Например, если у вас есть файл foo.bar затем вы можете встроить его в исполняемый файл, добавив следующие команды в ld

если вы призываете ld до gcc тогда вам нужно будет добавить -Wl

здесь —format=binary указывает компоновщику, что следующий файл является двоичным и —format=default переключается на формат ввода по умолчанию (это полезно, если вы укажете другой вход файлы после foo.bar ).

затем вы можете получить доступ к содержимому файла из кода:

есть также символ с именем «_binary_foo_bar_size» . Я думаю, что это типа uintptr_t но я не проверял его.

вы можете поместить все свои ресурсы в ZIP-файл и добавьте это в конец исполняемого файла:

это работает, потому что a) большинству исполняемых форматов изображений все равно, есть ли дополнительные данные за изображением, и b) zip хранит подпись файла в конец файла zip. Это означает, что ваш исполняемый файл является обычным zip-файлом после этого (за исключением вашего предварительного исполняемого файла, который может обрабатывать zip), который можно открыть и прочитать с помощью libzip.

недавно у меня возникла необходимость встроить файл в исполняемый файл. Поскольку я работаю в командной строке с gcc, et al, а не с причудливым инструментом RAD, который делает все это волшебным, мне не сразу стало ясно, как это сделать. Немного поиска в сети нашел хак, чтобы по существу cat его на конец исполняемого файла, а затем расшифровать, где это было основано на куче информации, о которой я не хотел знать. Казалось, должен быть лучший способ.

и есть, это objcopy для спасения. objcopy преобразует объектные файлы и исполняемые файлы из одного формата в другой. Один из форматов, который он понимает, — «двоичный», который в основном является любым файлом, который не находится в одном из других форматов, которые он понимает. Таким образом, вы, вероятно, предусмотрели идею: преобразуйте файл, который мы хотим встроить в объектный файл, тогда он может просто быть связанным с остальной частью нашего кода.

предположим, у нас есть данные имени файла.txt, который мы хотим внедрить в наш исполняемый файл:

чтобы преобразовать это в объектный файл, который мы можем связать с нашей программой, мы просто используем objcopy для создания «.o » file:

это говорит objcopy, что наш входной файл находится в формате» binary», что наш выходной файл должен быть в формате» elf32-i386 » (объектные файлы на x86). Опция —binary-architecture сообщает objcopy, что выходной файл предназначен для» запуска » на x86. Это необходимо, чтобы ld принял файл для связывания с другими файлами для x86. Можно было бы подумать, что указание выходного формата как «elf32-i386» подразумевает это, но это не так.

теперь, когда у нас есть объектный файл, нам нужно только включить его при запуске компоновщика:

когда мы запускаем результат, мы получаем молиться за выход:

конечно, я не рассказал всю историю однако, не показал тебе главного.c. Когда objcopy выполняет вышеуказанное преобразование, он добавляет некоторые символы «компоновщика» в преобразованный объектный файл:

после связывания эти символы указывают начало и конец внедренного файла. Имена символов формируются путем добавления бинарные и добавить _start и _end к имени файла. Если имя файла содержит символы, которые недопустимы в имени символа, они преобразуются в символы подчеркивания (например, сведения.txt становится data_txt). Если вы получить неразрешенные имена при связывании с помощью этих символов, сделать hexdump-C на объектном файле и посмотреть в конце дампа для имен, которые objcopy выбрал.

код для фактического использования встроенного файла теперь должен быть достаточно очевидным:

важно отметить, что символы, добавленные в объектный файл, не являются «переменными». Они не содержат никаких данных, скорее, их адрес является их значением. Я заявляю их как тип char, потому что это удобно для этого примера: внедренные данные являются символьными данными. Однако вы можете объявить их как угодно, как int, если данные являются массивом целых чисел, или как struct foo_bar_t, если данные были любым массивом баров foo. Если встроенные данные неоднородны, то char, вероятно, наиболее удобен: возьмите его адрес и наведите указатель на правильный тип по мере прохождения данных.

Если вы хотите контролировать точное имя символа и размещение ресурсов, вы можете использовать (или скрипт) ассемблер GNU (на самом деле не часть gcc) для импорта целых двоичных файлов. Попробуйте это:

сборка (x86 / arm):

что бы вы ни использовали, вероятно, лучше всего создать скрипт для генерации всех ресурсов и иметь хорошие/единообразные имена символов для всего.

могу ли я добавить, что метод Джона Рипли, вероятно, лучший здесь по одной огромной причине-выравнивание. Если вы делаете стандартную objcopy или » LD-r-B binary-o foo.о Фу.txt», а затем посмотрите на результирующий объект с objdump-x, похоже, что выравнивание для блока установлено в 0. Если вы хотите, чтобы выравнивание было правильным для двоичных данных, отличных от char, я не могу представить, что это хорошо.

читая все сообщения здесь и в Интернете, я сделал вывод, что нет инструмента для ресурсов, который :

1) простота использования в коде.

2) автоматизировано (быть легко включенным в cmake/make).

Источник