Reply With QuoteА чем стандартный путь не устраивает?
http://www.nslu2-linux.org/wiki/Optw...ckageToOptware
Тулчейн (свой) правда будет собираться долго. Если собирать не модуль ведра, а утилиту, то все вроде работает.
Зря испугались пути номер 2.
Переход от нативной компиляции к кросс-компиляции
Ниже на достаточно лёгком примере я попытаюсь собрать несложную сетевую утилиту, а Вы, коллеги, покажете, где в моих расуждениях засада.
Итак, преамбула.
Нативная компиляция, на мой взгляд, самый простой способ сборки ПО для роутера. Простота нативной компиляции состоит в том, что софт компилируется в самой благоприятной среде: общие библиотеки находятся в /opt/lib, заголовочные файлы в /opt/include, и пр. Кроме того, оценить получившийся результат можно сразу после компиляции. Но на ряду с простотой, нативный способ имеет следующие недостатки:
- долгое время компиляции софта,
- потенциальная нехватка памяти для работы компилятора,
- устаревший тулчейн (главный недостаток!),
- возможные проблемы с libtool, установленной в системе.
Перечислю инструменты, предлагаемые для кросс-компиляции:
- Старый тулчейн Олега. gcc 4.1.1(?) + uClibc 0.9.19. В качестве инструмента не рассматриваю, он устарел.
- Тулчейн Optware. gcc 4.1.1 + uClibc 0.9.28. Кстати, именно эта связка инструментов используется при нативной компиляции. После установки этот тулчейн отпугнул меня своей кучей скриптов на все случаи жизни. Чтобы начать с ним работать, необходимо разобраться с шаблоном скрипта template.mk и действовать аналогично. Честно говоря, я не хочу разбираться с этой кучей скриптов, и, тем более, искать причину если что-то пойдёт не так.
- Тулчейн энтузиастов, gcc 4.3.5 + uClibc 0.9.30.1. Этим тулчейном собирается сама прошивка. Собранный с помощью него софт пойдёт только на нашей коробочке и не запустится на других optware-based роутерах. На сайте прошивки есть два архива - hndtools-mipsel-uclibc-4.3.5-2.tar.bz2 и появившийся несколько дней назад hndtools-mipsel-uclibc-4.3.5-x86_64-3.tar.bz2. Бинарники из второго в последней Ubuntu у меня выполняться отказались и я выбрал в качестве инструмента первый архив. Этот инструмент мне понравился больше всего: в нём содержатся исключительно исключительно инструменты для компиляции. Никаких скриптов, как в варианте optware нет, поэтому различные зависимости для компилировния софта придётся прописывать самому, что лучше всего подходит для понимания процесса.
Теперь тестовый пример.
Маленькая сетевая утилита Ping Tunnel, имеющая одну зависимость. Как нельзя лучше подходит для примера.
Нативная компиляция.
Устанавливаем зависимости:
Скачиваем, распаковываем исходники и компилируем:Code:$ ipkg install libpcap libpcap-dev
Готово!Code:$ wget http://www.cs.uit.no/~daniels/PingTunnel/PingTunnel-0.71.tar.gz $ tar -xvzf ./PingTunnel-0.71.tar.gz $ cd PingTunnel/ $ make
Кросс-компиляция тулчейном энтузиастов.
- Устанавливаю тулчейн в ~/newtoolchain,
- В ~/newtoolchain/opt/lib и в ~/newtoolchain/opt/include кладу распакованные из ipk-пакетов файлы зависимой библиотеки libpcap.
- Правлю Makefile софтины, указывая перечисленные выше директории для компилятора и линковщика соответственно. Меняю компилятор с gcc на mipsel-linux-uclibc-gcc.
Code:# Makefile for the pingtunnel utility # (c) 2004-2009 Daniel Stoedle, daniels@cs.uit.no # ptunnel.exe target added by Mike Miller, mike@mikeage.net CC = mipsel-linux-uclibc-gcc CFLAGS = -Wall -g -I/home/al/newtoolchain/opt/include -I/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5/include LDOPTS = -lpthread -L/home/al/newtoolchain/opt/lib -L/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5 -lpcap PT_OBJS = ptunnel.o md5.o ...
- 4. Пытаюсь компилировать:
В чём засада?Code:$ make mipsel-linux-uclibc-gcc -o ptunnel ptunnel.o md5.o -lpthread -L/home/al/newtoolchain/opt/lib -L/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5 -lpcap /home/al/newtoolchain/opt/lib/libpcap.so: undefined reference to `__ctype_b_loc' collect2: ld returned 1 exit status make: *** [ptunnel] Ошибка 1
Last edited by ryzhov_al; 21-12-2010 at 21:21.
Zyxmon
А чем стандартный путь не устраивает?
http://www.nslu2-linux.org/wiki/Optw...ckageToOptware
Тулчейн (свой) правда будет собираться долго. Если собирать не модуль ведра, а утилиту, то все вроде работает.
Зря испугались пути номер 2.
Last edited by Zyxmon; 22-12-2010 at 06:30.
Смотри п.2.Originally Posted by Zyxmon
Forum Guru
gcc 3.2.3
Как легко догадаться, второй только для 64-битной системы. Свежий 32-битный выложит theMIROn, как сможет. Кросс-сборку 32-битного тулчейна на 64-битном хосте я еще не допилил, всё времени не хватает...На сайте прошивки есть два архива - hndtools-mipsel-uclibc-4.3.5-2.tar.bz2 и появившийся несколько дней назад hndtools-mipsel-uclibc-4.3.5-x86_64-3.tar.bz2.
Стандартные пути (/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5) не нужно включать, они подцепляются сами.Кросс-компиляция тулчейном энтузиастов.
Code:# Makefile for the pingtunnel utility # (c) 2004-2009 Daniel Stoedle, daniels@cs.uit.no # ptunnel.exe target added by Mike Miller, mike@mikeage.net CC = mipsel-linux-uclibc-gcc CFLAGS = -Wall -g -I/home/al/newtoolchain/opt/include -I/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5/include LDOPTS = -lpthread -L/home/al/newtoolchain/opt/lib -L/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5 -lpcap PT_OBJS = ptunnel.o md5.o ...
Скорее всего, придётся пересобрать и libpcap под нашу uClibc. Различие в конфиге - у нас выключено UCLIBC_HAS_LOCALE.В чём засада?Code:$ make mipsel-linux-uclibc-gcc -o ptunnel ptunnel.o md5.o -lpthread -L/home/al/newtoolchain/opt/lib -L/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5 -lpcap /home/al/newtoolchain/opt/lib/libpcap.so: undefined reference to `__ctype_b_loc' collect2: ld returned 1 exit status make: *** [ptunnel] Ошибка 1
Last edited by lly; 22-12-2010 at 08:57.
Значит, лучше не выделываться и собирать софт с помощью тулчейна optware. В противном случае нельзя будет использовать наработки optware.
Энтузиастский тулчейн оставить в покое и использовать только для сбора прошивки.
Forum Guru
В зависимости от твоих целей. Я всегда пересобираю из исходников нашим тулчейном
Взять хотя бы до сих пор неустранённые грабли с PIE бинарниками в optware (см. мои сообщения о баге в binutils)...
Если очень хочется бинарной совместимости с optware uClibc, надо наш тулчейн пересобирать с uClibc 0.9.29 и бекпортить пару пудов патчей из 0.9.30.1
Ну или спортировать фиксы в optware'вский тулчейн.
Last edited by lly; 22-12-2010 at 11:07.
причем второе гораздо кошернее
p.s. тулчейн x86 постараюсь сегодня выложить
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
наш тулчейн, помимо того, что озвучил lly позволяет использовать софт без optware, совсем.
с другой стороны, если есть куча зависимостей - их проще решать через optware
ASUS WL5xx: FW 1.9.2.7-d-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | bip irc proxy
ASUS RT-N1x: FW 1.9.2.7-rtn-rXXXX / обсуждение прошивки [RU] / firmware discussion [EN] | fake ident daemon
Как? Статической линковкой?
Получается так:
- при малом числе зависимостей лучше собирать новым тулчейном, перекомпилировав зависимости. Результат слинковать статически.
- если зависимостей много и пересобирать их задача нетривиальная, то лучше использовать тулчейн optware.
Так? Значит, от optware'овского тулчейна мне никуда не деться и вопрос выбора тулчейна закрыт
Кстати говоря, а чем присутствующие собирают ipk-пакет после компиляции? На www-просторах для этих целей есть куча самых разнообразных shell-скриптов. Тот, который использую я, имеет косяк в заполнении поля Description. Если в optware'овском тулчейне такой скрипт есть, то этот вопрос то же закрыт.
Last edited by ryzhov_al; 22-12-2010 at 14:04.
Forum Guru
зачем??? не выставляй LD_LIBRARY_PATH=/opt/lib и библиотеки из /lib найдутся сами. Ну можно добавить контрольный выстрел - rpath
Ну например http://wl500g.googlecode.com/svn/ipk...es/ipkg-utils/Кстати говоря, а чем присутствующие собирают ipk-пакет после компиляции?
Хотя бы за тем, чтобы не возник случай описанный в примере выше.
- Обновлённая uClibc возьмётся из /lib. Согласен,
- Зависимую libpcap всё равно придётся брать из /opt/lib.
Финиш. В примере из первого поста софтина, собранная с uClibc 0.9.30.1 не слинковалась с динамической библиотекой libpcap из optware, так как библиотека была собрана с uClibc 0.9.28.
Очень хорошо. Пару скриптов ipkg-build* утащил к себе в нору.
Forum Guru
Что мешает положить в /opt/lib пересобранную версию libpcap? Боишься, что кто-то еще будет использовать?
Ну тогда делать отдельную /opt/lib.new и прописывать rpath.
Zyxmon
Если используете optware, то все простоКстати говоря, а чем присутствующие собирают ipk-пакет после компиляции?
При сборке скриптами optware "жестко" проставляется rpath и uClibc, и все библиотеки будут браться из /opt/lib.Code:make mypackage-check
Если
То можно жить без uClibc и пр. в /opt/libНу или спортировать фиксы в optware'вский тулчейн.
За изобретательство велосипедов можно получить... лучи ненависти от пользователей.
Пока не встречу серьёзных ограничений optware'овского тулчейна, буду работать с ним. Рано или поздно, optware будет вынужден обновить свой инструментарий. Благо большую часть репозитория можно пересобрать хоть сейчас, на автопилоте.
Вопросов у меня ещё будет мореТе, что будут касаться нашей коробочки, буду задавать здесь.
Спасибо присутствующим! Помогли определиться с тулчейном.
Forum Guru
Увы, насколько я понимаю ситуацию, сейчас это делать банально некому. Герои вроде Олега появляются очень редко.
Posting Permissions
