Как выглядит индексный файл, созданный Linux «ar», в файле .a?
У меня есть архивный файл, созданный архиватором xilinx с использованием:
arm-xilinx-linux-gnueabi-ar -rs mylib.a
Заглянув внутрь с помощью ar -t mylib.a
показывает только коллекцию файлов .o. Но опция «s» предполагает добавление индексного файла для облегчения связывания. Как выглядит индексный файл?
@KamilCuk Мне просто нужно убедиться, что он там. Потому что мой компоновщик говорит, что его там нет. Если он есть, то я строю его неправильно. Если его нет, то мне нужно выяснить, почему.
Ваш вопрос буквально корректен? Вы используете ar, а не arm-xilinx-linux-gnueabi-ar -t? Бинарные файлы ПК могут не анализировать библиотеки Crosstool. Это корень проблемы? Не смешивайте основные инструменты с кросс-инструментами.
@artlessnoise Я был неосторожен со своим вопросом — да. НО: когда я пытаюсь загрузить статическую библиотеку, созданную xilinx, в другой среде сборки, она, конечно же, не может «видеть» индексный файл. Так что теперь я пытаюсь придумать, как еще его заархивировать.
@artlessnoise возможно ли вообще выполнить кросс-компиляцию проекта, но заархивировать его с помощью архиватора хост-компьютера? Или все инструменты должны быть ориентированы на одну и ту же платформу?
Я не совсем уверен. Просто кажется, что эта ошибка «проблема с индексным файлом» может быть связана с разными версиями/конфигурациями инструментов. GDB для экземпляров можно настроить как «многоархивный», но двоичный файл больше. Вполне возможно, что ar можно собрать только для одной архитектуры (обычно она является частью binutils). clang является мультиархитектурным (как и llvm), поэтому часто наборы инструментов/дистрибутивы, поддерживающие clang, будут иметь поддержку нескольких арочных архитектур. Во всяком случае, я бы не исключал некоторую несовместимость разных ar двоичных файлов (даже если версии совпадают, возможно, они настроены по-другому).
ar кажется немного странным. Это похоже на tar, но он также разрешает символы для компоновщика. Я предполагаю, что gold (или gnu ld) вызывает ar для разрешения символов. Искажение символов зависит от архитектуры, а формат архива tar — нет. Я почти уверен, что вы можете вставить случайный файл «.o» в любой ar (если нет какой-либо проверки). Проблема возникнет при их извлечении для разрешения имен.
@artlessnoise действительно, именно тогда возникает проблема (компоновщик жалуется на то, что «индекс не найден». Я создаю об этом отдельный пост. спасибо
Ответы 1
Таблица символов архива обычно называется /, // или __.SYMDEF и обычно представляет собой первую запись в архиве, начиная с
https://man.freebsd.org/cgi/man.cgi?query=ar&sektion=5 раздел Special Archive Members. Я возьму libz.a из своей системы и увижу:
$ hexdump -C libz.a| head -n 60
00000000 21 3c 61 72 63 68 3e 0a 2f 20 20 20 20 20 20 20 |!<arch>./ |
00000010 20 20 20 20 20 20 20 20 30 20 20 20 20 20 20 20 | 0 |
00000020 20 20 20 20 30 20 20 20 20 20 30 20 20 20 20 20 | 0 0 |
00000030 30 20 20 20 20 20 20 20 31 36 38 34 20 20 20 20 |0 1684 |
00000040 20 20 60 0a 00 00 00 69 00 00 06 d8 00 00 06 d8 | `....i........|
00000050 00 00 06 d8 00 00 06 d8 00 00 13 1c 00 00 13 1c |................|
00000060 00 00 13 1c 00 00 13 1c 00 00 13 1c 00 00 13 1c |................|
00000070 00 00 13 1c 00 00 13 1c 00 00 48 18 00 00 48 18 |..........H...H.|
Первая запись / имеет размер 1684 байта. Затем я могу извлечь индексный файл и «показать» его вам. Индексный файл «выглядит» следующим образом:
$ dd if=libz.a bs=1 skip=68 count=1684 status=none | hexdump -e '"%_c"'
\0*
i\0*
006330\0*
006330\0*
006330\0*
006330\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
023034\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
H030\0*
236334\0*
236334\0*
236334\0*
3158\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0*
331t\0001,310\0001,310\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001;004\0001t030\0001t030\0001t030\0001t030\0001t030\0001t030\0001177004\0001177004\0001177004\00012100\00012100\0001222034\0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001230 \0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001275,\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`\0001337`adler32_z\0adler32\0adler32_combine\0adler32_combine64\0get_crc_table\0crc32_z\0crc32\0crc32_combine64\0crc32_combine\0crc32_combine_gen64\0crc32_combine_gen\0crc32_combine_op\0deflateSetDictionary\0deflateGetDictionary\0deflateResetKe*
p\0deflateReset\0deflateSetHeader\0deflatePending\0deflatePrime\0deflateTune\0deflateBound\0deflate\0deflateParams\0deflateEnd\0deflateInit2_\0deflateInit_\0deflateCopy\0deflate_copyright\0inflateBackInit_\0inflateBack\0inflateBackEnd\0inflate_fast\0inflateResetKe*
p\0inflateReset\0inflateReset2\0inflateInit2_\0inflateInit_\0inflatePrime\0inflate\0inflateEnd\0inflateGetDictionary\0inflateSetDictionary\0inflateGetHeader\0inflateSync\0inflateSyncPoint\0inflateCopy\0inflateUndermine\0inflateValidate\0inflateMark\0inflateCodesUsed\0inflate_table\0inflate_copyright\0_length_code\0_dist_code\0_tr_init\0_tr_stored_block\0_tr_flush_bits\0_tr_align\0_tr_flush_block\0_tr_tal*
y\0zlibVersion\0zlibCompileFlags\0zEr*
or\0z_er*
msg\0zcal*
oc\0zcfre*
\0compres*
2\0compres*
\0compres*
Bound\0uncompres*
2\0uncompres*
\0gzclose\0gzopen\0gzopen64\0gzdopen\0gzbuf*
er\0gzrewind\0gzse*
k64\0gzse*
k\0gztel*
64\0gztel*
\0gzof*
set64\0gzof*
set\0gzeof\0gzer*
or\0gzclearer*
\0gz_er*
or\0gz_intmax\0gzread\0gzfread\0gzgetc\0gzgetc_\0gzungetc\0gzgets\0gzdirect\0gzclose_r\0gzwrite\0gzfwrite\0gzputc\0gzputs\0gzvprintf\0gzprintf\0gzflush\0gzsetparams\0gzclose_w\0*
Тем не менее, я не считаю «похожий» очень полезным.
Что именно вы получаете, просматривая индексный файл?
But the 's' option is supposed to add the index file to facilitate linkageДобавляет в архив индексный "файл", он как бы внутренний.