Давно знал про существование маленького шустрого компилятора TCC http://bellard.org/tcc/ от создателя qemu. Недавно вспомнил про него - он оказывается для arm умеет бинарники делать, но к сожалению только как кросс-компилятор на х86. Собственно в чем его преимущества
он в 10!!! раз быстрей gcc собирает ядро и вообще любые бинарники. Я им баловался на х86 давно - в общем исходники на С с ним можно запускать как скрипты - он их на лету компилирует :) Был даже проект загрузки linux правда там для ядра патчи нужны были из исходников - ядро собиралось налету в процессе загрузки. Пользоваться им скорей практически нереально будет :) но все же как еще один вариант :) жаль что он под арм как нативный не умеет работать... сам его бинарник всего 300 кбайт. Вообще я искал маленький нативный С/С++ компилятор для арм... Не нашел :)
Похоже ты всеже прав - я только сегодня это заметил. Пользовался одним и тем же срезом buildroot - первый раз собирал когда тулчайн был еще там куда его скопировал crosstool-ng а потом он видимо просто линкует существующие объектные файлы - поэтому я это сразу не заметил, сборка проходила без ошибок.
repairman,
сам в линуксе новичок, может подскажите в чем может быть проблема. Скачал http://repairman.smtp.ru/armv5l-linux-uclibc.tar.bz2, распаковал. собираю простой тест.
собираю статически (./armv5l-linux-uclibc-gcc ./test.c -o test_stat -static
) и динамически (./armv5l-linux-uclibc-gcc ./test.c -o test_dll
).
копирую на флешку (ext2) тесты и все содержимое armv5l-linux-uclibc/sys-root. Подключаю флешку к плате, монтирую, обновляю LD_LIBRARY_PATH.
тест, собранный статически запускается, динамически - нет.
Так нету в этой директории файла test_dll... (???)
Путь к библиотекам прописан жестко в каждом бинарнике как /lib
Если их там нет, я вижу такое:
Вообще я не понимаю как Вы собираетесь работать имея одновременно и glibc и uclibc... Выберите что-то одно, вместе они жить не будут, хотя бы потому, что выполняют одинаковые функции, имеют одно и то же статическое место расположения и, частично, одинаковые имена файлов...
Если rootfs собрана с glibc - значит вам нужен glibc-тулчейн с ЭТОЙ ЖЕ версией glibc, чтобы бинарники работали сразу без колдовства и извращений... если с uclibc - значит uclibc тулчейн и нужные библиотеки уже лежат в ожидаемом месте... никаких библиотек, LD_LIBRARY_PATH, ldconfig - НЕ НУЖНО.... все уже есть на rootfs...
p.s. скопировал библиотеку и линк на нее в /lib на rootfs - и файл запустился...
... но IMHO, это неправильно и будут вилы... в этой библиотеке НЕ ВСЁ...
Добрый день!
Используя выше приведенные конфиги, я собрал свой toolchain с uClibc. С использованием этого toolchain-а, все вроде собиралось хорошо,
но тут столкнулся с небольшой проблемой при сборке самого ядра (2.6.28.5) используя данный ToolChain :
собранный тулчейн называется arm-none-linux-uclibcgnueabi
1. Сборку делаю как и обычно, но указываю новый тулчейн
2. Далее делаю сборку бинарника
и тут на выходе я получаю Linux.bin c размером около 3 гигов!!! И это при том, что vmlinux около 3 метров,
размер сопостовим с размером при использовании стандартного тулчейна (который идет с платой) arm-none-linux-gnueabi
и с ним на выходе получаем linux.bin около 3 метров. (если все компилировать изначатьно используя arm-none-linux-gnueabi)
При проведении сжатии
получаем размер около 4 метров, что говорит, что в linux.bin (в 3 гигах) есть какая-то пустота с мусором.
Может, кто сталкивался с этим? Уже сутки бьюсь, т.к. использование uClibc мне очень необходимо в связи с увеличившимися размерами при использовании стандартной библиотеки.
P.S. Сейчас решил все пройти с чистого листа (компиляцией своего тулчейна, ядра, рутфса и т.д.) и записать все телодвижения для создания полноценной инструкции. Надеюсь, что сильно поможет всем остальным.
С UBoot идет утилитка mkimage, которая из стандартной zImage, получаемой при сборке ядра, делает нужную UBoot - uImage.
Пользуюсь таким скриптом:
p.s. заметил интересную вещь... похоже формат uImage менялся, т.к. образы сгенеренные новым mkimage старые UBoot не воспринимают (ошибка CRC)... т.е. mkimage должен быть от Вашей версии UBoot.
Проблем с размером не замечал... стандартный размер файла 0.9-1.7 мб
Согласен, но mkimage применяется несколько позднее. А именно:
1. После сборки ядра получаем vmlinux
2. Переводим в бинари
3. Сжимаем
4. Готовим имадж для uBoot
Это я взял с авторского диска. Возможно, что-то тут и лишнее (в цепочке). У меня после сборки ядра, на выходе, получается vmlinux, далее я его сжимаю (до сжатия он 4 метра, а после 1,5), в сжатом отдаю mkimage для подготовки. У Вас, видимо, все делается без сжатия. Или я где-то упустил этот момент? Но без сжатия добиться размера 0,9-1,5 думаю не реально.
Не сложно ли также сказать какой командой/настройкой вы делаете конфигурацию uBoot перед сборкой. Т.к. хотелось бы пересобрать uBoot, но не получается.
Для SK необходимо поправить файл include/configs/at91sam9260dfc.h на предмет верной частоты генератора, объема ОЗУ и адреса ядра.
Также, чтобы сеть работала - подложить ему модуль ks8721bl.c (например из авторского комплекта) вместо dm9161...
UBoot 1.3.4, UBoot 2009.01 - собираются, работают, НО в них изменена работа сети... пока не получается ks8721 туда прицепить...