gcc-4.3.4 (static) с библиотекой, отличной от glibc под x86_64
Aq_RB 8 февраля, 2010 - 23:40
Уважаемые господа!
Кто-нибудь собирал успешно gcc с uClibc со статической компоновкой?
Сборка обрывается на stage1. libiberty, libmudflap, прочие «внутренние» библиотеки собираются успешно. Не собиратеся сам gcc: в файле regex.c в инклюде real.h:82 длина массива char* test_real_width равна -1. По-видимому, из-за того, что какие-то препроцессорные константы чему-то не тому равны, сейчас буду разбираться, повставляю #warning'и.
Если у кого-то была подобная ошибка, прошу отписаться. :-)
»
- Для комментирования войдите или зарегистрируйтесь
Предварительное расследование кое-что прояснило
Итак, немного изнасиловав файл $SRCDIR/gcc/real.h разными директивами, удалось выяснить значение некоторых важных констант:
EXP_BITS == 32-6 == 26
HOST_BITS_PER_LONG == 32
SIGNIFICAND_BITS == HOST_BITS_PER_LONG+128 == 160
SIGSZ == (SIGNIFICAND_BITS/HOST_BITS_PER_LONG) == 160/32 == 5
HOST_BITS_PER_WIDE_INT == 64
Теперь по поводу битового поля real_value:
REAL_VALUE_TYPE_SIZE == 192 (бита)
REAL_WIDTH == (192/64 + (192%64 ? 1 : 0)) == 3+0 == 3
sizeof(REAL_VALUE_TYPE) == 48 (байт)
sizeof(HOST_WIDE_INT) == 8 (байт)
В структуре real_value комментируя последнюю строку получаем размер 4 байта == 2+1+1+1+1+26 == 32 бита.
Если оставить тоько последнюю строку, то размер будет unsigned long [5] == 40 байт.
Таким образом, получается, что sizeof(ulong) == 40/5 == 8 байт == 64 бита! При том, что HOST_BITS_PER_LONG равно 32 бита.
Поглядев ещё немного, увидел, что HOST_BITS_PER_LONG определяется как CHAR_BIT*SIZEOF_LONG. Буду ковырять дальше, так как одна из этих двух констант где-то определяется неправильно.
the Aquihost Rigorous Builder
А значит ли это, что в
А значит ли это, что в дальнейшем emerge e system (в дальнейшем world) так же стопарнется на этих же граблях ?
PS [товарищ] подделитесь мозгами на пару недель, я их угощу алкоголем, и законспектирую содержимое... ;))
知る者は言わず言う者は知らず
"Бабло, побеждает даже зло"
Выпрямление собственных рук -- процесс долгий и трудный
Если всё будет сконфигурировано также криво, как и у меня, то да, будут проблемы. ;-))) А если всё как надо -- то не стоит волноваться.
Я разобрался.
Проблема была в том, что для сборки некоторых компонент подхватывался 32-битный компилятор, он и давал неправильный sizeof(long). У меня стоят параллельно две версии gcc, вызываемые командами gcc32 и gcc64 соответственно, а также набор символических ссылок, указывающий на нужный в данный момент инструментарий. Я в последний раз собирал что-то 32-битное, а ссылки перегенерировать забыл. Но для сборки нового gcc-4.3.4 прописал непосредственно CC="gcc64" CC_FOR_TARGET=$CC. Вроде configure-скрипты должны отрабатывать правильно, но некоторые из них тупо подразумевают CC=gcc, и плевать им на всякие переменные окружения. Вот из-за этого некоторе куски и собрались у меня с неправильным компилятором.
Походу gcc-4.3.4 так и не получилось собрать. После создания временного компилятора xgcc почему-то make пытается вызывать компилятор для таргета, хотя его сразу после stage1 быть просто не может. Ладно, поправил Makefile. Тут выясняется, что у xgcc нету спеков, которые ему указывают, где искать библиотеки и инклюды. :-(
Потом просто удалил gcc-4.3.4, скачал gcc-4.4.3, запустил с тем же конфигом, и он успешно собрался. Правда, инклюды ищет не там где положено :-( буду разбираться дальше, где накуролесил.
Прошу, если кто в курсе, рассказать мне, как задавать спеки для gcc при кроссовой сборке. Потому что в документации я этого не нашёл. С меня -- благодарность и лучи любви.
Поделитесь, где можно бедному криворукому чайнику поговорить с разрабами gcc по-русски. А то в Инглиш моуд я ридонли. ;-))
the Aquihost Rigorous Builder