Мне хотелось бы использовать линукс на ноуте (Ubuntu 10.04, x86) в качестве билд-машины. Однако, после того как я взял прилагающийся кросс-компилятор и собрал им ядро (2.6.28), я обнаружил чрезвычайно странную проблему --- ядро (файл vmlinux) имело размер 28Мб против ядра в 8Мб, собранного на эталонной билд-машине.

Анализ показал, что в секции .init один из символов (и все последующие) сдвинулся на 20Мг и имеет адрес c16xx против c02xxx в эталонной машине. К сожалению, причины столь странного явления я не понял, сам бинарный код оботх ядер в остальном совпадает, кроме файлов типа version.o.

Нет ли предположений, что здесь не так, и что нужно билд машине кроме кросс-компилятора?

Есть ли исходники именно этого кросс-компилятора вместе со сценарием сборки? Хотелось бы его пересобрать в качестве последней меры.

Цитата

Мне хотелось бы использовать линукс на ноуте (Ubuntu 10.04, x86) в качестве билд-машины. Однако, после того как я взял прилагающийся кросс-компилятор и собрал им ядро (2.6.28), я обнаружил чрезвычайно странную проблему --- ядро (файл vmlinux) имело размер 28Мб против ядра в 8Мб, собранного на эталонной билд-машине.

Помимо виртуалки от Павла с RedHut я использую VM с самопоставленным кросскомпиллером (3.4.1 и 3.3?), брал еще в инете нечто arm-none-gnueabi-. Все нормально работало и собирало ядра нормального размера..
могу предположить, что у вас к ядру "пристегивается" рутфс - т.с. все в одном флаконе - отсюда и безумный размер бинарника.
ну а пересобирать кросскомпиллер мне кажется - это перебор :)

Цитата

Нет ли предположений, что здесь не так, и что нужно билд машине кроме кросс-компилятора?

Вы случайно отладочную информацию не включили при сборке ядра ? Хотя судя по всему вы из кто знает что делает... один раз была подобная проблема - но у меня получался упакованный бинарь гигантских размеров.

Цитата

Есть ли исходники именно этого кросс-компилятора вместе со сценарием сборки? Хотелось бы его пересобрать в качестве последней меры.

Значит я из тех кто всегда использует последние меры :) никогда не пользуюсь готовым тулчейном и всегда собираю его этим:

http://ymorin.is-a-geek.org/projects/crosstool

Это старая проблема (objcopy не все что надо скармливается). Собирайте ядро как make uImage или make zImage и берите его из arch/arm/boot тогда с любым toolchain будет нормального размера.

Цитата

Это старая проблема (objcopy не все что надо скармливается).

Увы, у меня все плохо как раз после make zImage ARCH=arm CROSS_COMPILE=..., а не после objcopy. Итог: zImage в 24Мб.

Пойду собирать тулчейн... Но мне кажется проблема не в этом.

Цитата

Пойду собирать тулчейн... Но мне кажется проблема не в этом.

попробуйте вот такой (я им собираю под дебьяном для 9260) ~41MB
http://www.handhelds.org/download/projects/toolchain/arm-linux-gcc-3.4.1.tar.bz2

ну и приведите строки сборки - может там где ошибка есть :)

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

Мда, дело явно не в тулчейне (собрал crosstool-ng, те же самые 24 метра ядро).

Видимо я где-то туплю.

Нет, я не включил отладочную информацию в ядре (и вообще не менял его конфиг по сравнению с эталонным).

Цитата

Мда, дело явно не в тулчейне (собрал crosstool-ng, те же самые 24 метра ядро).

Не расстраивайтесь - хороший тулчейн никогда не будет лишнимм ;-)

Цитата

Нет, я не включил отладочную информацию в ядре (и вообще не менял его конфиг по сравнению с эталонным).

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

Цитата

Мда, дело явно не в тулчейне (собрал crosstool-ng, те же самые 24 метра ядро).

а внутрь бинарника не заглядывали? там мусор или есть какие-нить ASCII строчки - может по ним можно идентифицировать корень проблем
ядро собираете самостоятельно или скрипт от Павла?