#gcc #static-libraries #elf #tizen
#gcc #статические библиотеки #elf #tizen
Вопрос:
Я пытаюсь создать zlib с помощью набора инструментов Tizen. Предполагается, что в рамках процесса сборки исходные файлы должны быть скомпилированы в объекты с arm-linux-gnu-eabi-gcc -c
, а затем объединены в архив с libtool
, но libtool
сбой и жалобы на то, что каждый из .o
файлов передан ему is not an object file (not allowed in a library)
.
После проверки я обнаружил, что arm-linux-gnu-eabi-gcc -c
это генерирует файлы ELF, а не объектные файлы, чего я раньше не видел. Когда я перехожу -c -v
к компилятору, я вижу, что компоновщик не вызывается. Итак, почему формат ELF?
Затем я попытался вызвать arm-linux-gnu-eabi-gcc -S
, за которым следует arm-linux-gnu-eabi-as
, и обнаружил, что сам ассемблер генерирует файлы ELF.
Вот пример:
% echo "int main(void) { return 0; }" > main.c
% arm-linux-gnueabi-gcc main.c -S -o main.s
% arm-linux-gnueabi-as main.s -o main.o
% file main.o
main.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
Набор инструментов Tizen включает в себя четыре компилятора ({i386, arm} и {4.6,4.9}). Все четыре ведут себя одинаково.
По крайней мере, это arm-linux-gnueabi-gcc
согласуется, потому что я могу передать ему несколько .o
файлов ELF, и, похоже, они правильно их связывают. Но мне все еще нужно иметь возможность генерировать реальные объектные файлы, чтобы их можно было архивировать в статическую библиотеку libtool
. Есть предложения?
Ответ №1:
генерирует файлы ELF, а не объектные файлы,
Вы очень смущены: ELF
и объектные файлы не являются эксклюзивными, а в Linux все объектные файлы являются ELF
. Другими словами, это работает так, как ожидалось.
ELF
файлы могут иметь разные типы: ET_REL
(перемещаемые объектные файлы), ET_DYN
(разделяемые библиотеки) и ET_EXEC
(исполняемые файлы).
Мне все еще нужно иметь возможность генерировать реальные объектные файлы, чтобы их можно было архивировать в статическую библиотеку с помощью libtool
Проблема, вероятно, в том, что libtool
он не распознает неродные ELF
.o
файлы как нечто, что он может поместить в архивную библиотеку.
В общем, libtool
это почти всегда неправильное решение проблемы, независимо от того, в чем проблема. Его заявленная цель — «скрыть сложность использования разделяемых библиотек за согласованным переносимым интерфейсом». По моему опыту, он явно не достигает этой цели на всех платформах.
Конечно, если вы просто хотите поместить кучу .o
файлов в архивную библиотеку, правильный способ сделать это — просто использовать *-linux-gnueabi-ar
which не должно возникнуть проблем.
Комментарии:
1. Интересные мысли
libtool
. Я сам им не пользовался, но, похоже, многие проекты его используют, и я использую его здесь просто потомуzlib
, что этого хочет.2. Я думаю, что я знал, что объекты были
ELF
файлами, но забыл об этом в процессе сборки. Спасибо за объяснение. В итоге я решил проблему, убедившись, что переменная средыAR
была правильно определена, чтобыlibtool
она могла вызывать нероднуюar
, на которую вы ссылались.