Ассемблер Tizen gcc, генерирующий ELF вместо объектных файлов — не удается создать статическую библиотеку

#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 , на которую вы ссылались.