Проклятие кросс-компилятора

[kincajou]

даже по инструкции с IBM developerWorks не получается собрать!
вернее, собирается-то он собирается, но вот новособранный компил glibc уже не хочет компилить. Вывод - что-то где-то опять криво собралось. Чудеса в решете, блин... это было бы смешно.

Вот что я делаю, по шагам:


# config.guess
x86_64-redhat-linux-gnu

# export TARGET=i386-pc-linux-gnu
# export PREFIX=/usr/local/crossgcc
# export TARGET_PREFIX=$PREFIX/$TARGET
# export PATH=$PATH:$PREFIX/bin

# mkdir $TARGET_PREFIX/include
# cd /opt/i386-linux-toolchain/linux-2.4.18
# make ARCH=i386 CROSS_COMPILE=$TARGET menuconfig
...куча бла-бла-бла
# cp -rv include/linux $TARGET_PREFIX/include
...куча бла-бла-бла
# cp -rv include/asm-i386 $TARGET_PREFIX/include/asm
...куча бла-бла-бла
# cp -rv include/asm-generic $TARGET_PREFIX/include/
...куча бла-бла-бла

# cd ../binutils-build
# ../binutils-2.16/configure --target=$TARGET --prefix=$PREFIX -disable-nls -v; make; make install
...куча бла-бла-бла

# cd ../gcc-build
# ../gcc-4.1.0/configure --target=$TARGET --prefix=$PREFIX --without-headers --with-newlib -v
...куча бла-бла-бла
# make all-gcc; make install-gcc
...куча бла-бла-бла. Вроде всё ок. Решаю проверить...
# i386-pc-linux-gnu-gcc /opt/test/test.c -o /opt/test/t
/usr/local/crossgcc/lib/gcc/i386-pc-linux-gnu/4.1.0/../../../../i386-pc-linux-gnu/bin/ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found (try using -rpath or -rpath-link)
Сие говорит нам, что линковщик не может загрузить правильные библиотеки (или что там грузит это самое ld-linux.so), но тем не менее...
# objdump -G /opt/test/t
/opt/test/t: file format elf32-i386
...сгенерился правильный код для i386. Успокоения ради и для проверки наших чувств:
# gcc /opt/test/test.c -o /opt/test/t2
# objdump -G /opt/test/t2
/opt/test/t2: file format elf64-x86-64
# /opt/test/t
Hi!
# /opt/test/t2
Hi!
то бишь оба бинарника работают и второй, как того и следовало ожидать, собрался под x86_64 штатным компилером. Теперь пришло время собрать glibc
# cd ../glibc-build
# CC=${TARGET}-gcc ../glibc-2.4/configure --target=$TARGET --prefix=$PREFIX --with-headers=${TARGET_PREFIX}/include
...куча бла-бла-бла, среди которого попадается вот это:
running configure fragment for sysdeps/x86_64/elf
checking for x86-64 TLS support... no
смотрю в config.log:

configure:6: checking for x86-64 TLS support
configure:25: i386-pc-linux-gnu-gcc -c -g -O2 conftest.s 1>&5
conftest.s: Assembler messages:
conftest.s:8: Error: @TLSLD reloc is not supported in 32 bit mode
conftest.s:8: Error: junk `@TLSLD' after expression
conftest.s:8: Error: `bar@TLSLD(%rip)' is not a valid base/index expression
conftest.s:9: Error: bad register name `%rax)'
conftest.s:10: Error: `foo@GOTTPOFF(%rip)' is not a valid base/index expression
conftest.s:11: Error: bad register name `%rdx'
configure:28: $? = 1
configure:36: result: no

То бишь получившийся кросс-ассемблер (из бинутилсов) не поддерживает это самое TLS. И не понятно, как это лечить, в опциях конфигуратора бинутилсов TLS вроде не упоминается. В общем, запускаем...
# make all
И видим кучу строк с сообщениями типа

In file included from include/tls.h:6,
                 from sysdeps/unix/sysv/linux/x86_64/sysdep.h:26,
                 from :1:
nptl/sysdeps/x86_64/tls.h:62:3: error: #error "TLS support is required."

И всё, на этом всё прекращается (ясен перец)

Кто знает, как это побороть? Или кто знает кого-то, кто знает, как это побороть?

Comments

Обещанный идиотский вопрос..

[dreimora.livejournal.com]

Сие говорит нам, что линковщик не может загрузить правильные библиотеки (или что там грузит это самое ld-linux.so), но тем не менее...

Ммм... прости, а где прописан путь к нужным библиотекам? А он правильно прописан?
А в этом пути библиотеки в нужном порядке стоят, или как попало?

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

Re: Обещанный идиотский вопрос..

[dreimora.livejournal.com]

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

Re: Обещанный идиотский вопрос..

[kincajou.livejournal.com]

да, в общем-то, так и есть

Re: Обещанный идиотский вопрос..

[kincajou.livejournal.com]

путь к нужным библиотекам не нужен, на самом деле. Для этого ключи --with-newlib и --without-headers нужны (второй говорит о том, что не надо использовать заголовки от ещё не созданной библиотеки, а первый говорит конфигуратору о том, чтобы он думал, что библиотека newlib есть (это аналог glibc, но для встраиваемых систем))

а вообще вот он, этот путь:
/lib

а ld-linux.so.2 находится вот тут:
/lib/ld-linux.so.2

(совсем сходя с ума)

[dreimora.livejournal.com]

а почему utils генерятся перед библиотеками??

(если я вообще хоть как-то понимаю, что там происходит..)

Re: (совсем сходя с ума)

[kincajou.livejournal.com]

потому что С-компилятор работает так:

сначала препроцессор разворачивает все директивы, макросы и т.п.

затем парсер пробегает по всему получившемуся С-коду и делает из него ассемблерный код

потом вызывает ассемблер, который делает байт-код

потом вызывает линкер, который берёт этот код и библиотеки, и делает из них исполняемый бинарник

Вот. Чтобы что-то заработало, нужны бинутилсы.

Еще один идиотский вопрос

[dreimora.livejournal.com]

Если там где-нибудь в properties файлах или как там оно все работает есть упоминание об этом загадочном TLS, нет ли там где-нибудь настроечной константы, утверждающей, что данная непонятная штука будет теперь работать в 32 bit mode ??

Re: Еще один идиотский вопрос

[kincajou.livejournal.com]

я не нашёл упоминаний, как это включить или выключить

и совсем дебильное, напоследок

[dreimora.livejournal.com]

Если эта загадочная фигня TLS отказывается работать в 32-bit mode, почему весь режим целиком называется x86_64 ???

Я понимаю, это паранойя, но тем не менее?

Re: и совсем дебильное, напоследок

[kincajou.livejournal.com]

потому что кросс-компилятор будет работать на x86_64, но генерить код для i386. На то он и кросс.

ой.

[dreimora.livejournal.com]

Ощущение, что он собрался для обратной цели....
Знаю, что дурь, но вот полное впечатление, что он наоборот пытается..

Re: ой.

[kincajou.livejournal.com]

вроде TARGET однозначно видно, так что природа твоего ощущения мне не ясна

еще, чистое от невежества

[dreimora.livejournal.com]

export TARGET_PREFIX=$PREFIX/$TARGET
что значит тут $ перед наименованиями prefix и target и что значат эти самые названия?

А то у меня закралось совсем дикое предположение, что сначала оно инициализирует префиксы в одном месте, а потом генерит пустую папку и пытается брать значение префиксов из нее... Но, скорее всего, я просто не въезжаю совсем, что там происходит....

Re: ой.

[kincajou.livejournal.com]

$значит, что следующие символы - это не просто текстовая строка, а имя системной переменной. Команда export помещает переменную в окружение. Если развернуть упомянутую тобой конструкцию, то получится, что
TARGET_PREFIX=/usr/local/crossgcc/i386-pc-linux-gnu

[opensourcer.livejournal.com]

Есть предложение поставить куда-нибудь в vmware или в chroot слаку и не насиловать моск кросскомпиляторами.

Упадочный стиль

[kincajou.livejournal.com]

можно ещё проще - скачать rpm с нужным компилом. Но это неспортивно.

[potan.livejournal.com]

Что-то слышал про то, что glibc-2.4 требует ядро 2.6.
Можно попробовать сконфигурить glibc с опциями --without-tls или --enable-add-ons=nptl

[kincajou.livejournal.com]

так и есть, требует
но это не важно - glibc-2.2.5 точно так же не собирается