Page 1 of 6 123 ... LastLast
Results 1 to 15 of 143

Thread: Переход от нативной компиляции к кросс-компиляции

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Thumbs up Переход от нативной компиляции к кросс-компиляции

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

    Итак, преамбула.

    Нативная компиляция, на мой взгляд, самый простой способ сборки ПО для роутера. Простота нативной компиляции состоит в том, что софт компилируется в самой благоприятной среде: общие библиотеки находятся в /opt/lib, заголовочные файлы в /opt/include, и пр. Кроме того, оценить получившийся результат можно сразу после компиляции. Но на ряду с простотой, нативный способ имеет следующие недостатки:
    • долгое время компиляции софта,
    • потенциальная нехватка памяти для работы компилятора,
    • устаревший тулчейн (главный недостаток!),
    • возможные проблемы с libtool, установленной в системе.


    Перечислю инструменты, предлагаемые для кросс-компиляции:
    1. Старый тулчейн Олега. gcc 4.1.1(?) + uClibc 0.9.19. В качестве инструмента не рассматриваю, он устарел.
    2. Тулчейн Optware. gcc 4.1.1 + uClibc 0.9.28. Кстати, именно эта связка инструментов используется при нативной компиляции. После установки этот тулчейн отпугнул меня своей кучей скриптов на все случаи жизни. Чтобы начать с ним работать, необходимо разобраться с шаблоном скрипта template.mk и действовать аналогично. Честно говоря, я не хочу разбираться с этой кучей скриптов, и, тем более, искать причину если что-то пойдёт не так.
    3. Тулчейн энтузиастов, 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
    Готово!

    Кросс-компиляция тулчейном энтузиастов.
    1. Устанавливаю тулчейн в ~/newtoolchain,
    2. В ~/newtoolchain/opt/lib и в ~/newtoolchain/opt/include кладу распакованные из ipk-пакетов файлы зависимой библиотеки libpcap.
    3. Правлю 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 20:21.

  2. #2
    А чем стандартный путь не устраивает?
    http://www.nslu2-linux.org/wiki/Optw...ckageToOptware

    Тулчейн (свой) правда будет собираться долго. Если собирать не модуль ведра, а утилиту, то все вроде работает.
    Зря испугались пути номер 2.
    Last edited by Zyxmon; 22-12-2010 at 05:30.

  3. #3
    Quote Originally Posted by Zyxmon View Post
    А чем стандартный путь не устраивает?
    http://www.nslu2-linux.org/wiki/Optw...ckageToOptware
    Смотри п.2.

  4. #4

    Optware такой optware

    Quote Originally Posted by Zyxmon View Post
    А чем стандартный путь не устраивает?
    http://www.nslu2-linux.org/wiki/Optw...ckageToOptware
    ...
    Зря испугались пути номер 2.
    Потратил вечер, чтобы разобраться со сборочными скриптами optware и успешно пересобрал свой пример. Как и ожидалось, основные усилия пришлось затратить на подстройку под логику работы тулчейна. Если полностью принять эту логику, то процесс автоматизируется вплоть до пересборки зависимостей и выкатывания на финише готового ipk-пакета. Что одновременно и хорошо, и плохо:
    • Хорошо тем, что такая автоматизация - мечта мейнтейнера. Скрипты сами скачают обновлённые исходники, накладывают на них патчи, конфигурируют и собирают исходники, результат собирают в ipk-пакет.
    • Плохо тем первопроходцам, что собирают новый софт из (в основном чужих) исходников. Так как подобная автоматизация оказывает в этом случае медвежью услугу.

    На втором случае остановлюсь подробнее. Первая засада ждёт в самом начале работы:
    1. указал в шаблоне make-файла для новой софтины откуда скачивать исходники,
    2. получил первую ошибку при сборке с помощью тулчейна optware,
    3. подправил make-файл софтины и перезапустил сборку.

    В этом случае, скрипты не обнаружив в каталоге исходников софтины флаг .configured, сроют к чертям все изменения и заново распакуют исходники. Отсюда первый костыль - запись в каталог исходников флага .configured. Причём при работе анализируется время изменения этих флагов. Засада с флагами возникает на каждом шагу:
    • если Makefile новее бинарника - убить бинарник!
    • если флаг .build старее бинарника - убить бинарник!
    • если нет флага .configured (см.выше) - убить исходники!
    • если бинарник новее ipk-пакета - убить пакет!
    • и прочая, и прочая.

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

    Вторая засада в том, что тулчейн в своих шаблонах надеется обнаружить использование libtool для конфигурирования софтины. Если же такового нет (как в примере), то все телодвижения скриптов optware до начала компиляции тщетны. Для моего примера мне пришлось просто "украсть" значения переменных GCC, LDOPTS и пр. у optware-скриптов. Другой путь в этом случае - писать скрипт-заглушку configure в директории исходников софтины для сохранения полученных от optware настроек.

    Вот по этим перечисленным причинам я вначале остановил свой выбор на тулчейне энтузиастов. Мне не пришлось бы потратить на разбор скриптов вчерашний вечер. Но в связи с тем, что от тулчейна optware далеко не уйдёшь, можно сделать вывод:
    • хочешь постоянно поддерживать актуальным какой-нибудь пакет в репозитории - положись на скрипты optware,
    • взялся за непаханые сырцы - держись от них подальше. Всё равно тебе от этих скриптов в итоге нужны будут только ключи для компиляции и линковки и пара shell-скриптов для сборки пакета перед тем как обнародовать свои наработки.
    Last edited by ryzhov_al; 23-12-2010 at 07:15.

  5. #5
    Я в основном подправлял готовые пакеты.

    Пара замечаний.

    В качестве источника исходников наверняка можно указывать
    file://......

    Ну а что и когда убивается - логика Makefile такая.
    После configure можно запускать кросскомпиляцию в папке с исходниками через make.

    strip в optware делается автоматически при сборке ipk.
    Last edited by Zyxmon; 23-12-2010 at 08:25. Reason: spelling

  6. #6
    Join Date
    Feb 2007
    Location
    Moscow, Russia
    Posts
    3,805
    3. подправил make-файл софтины и перезапустил сборку.
    в optware исходники править не полагается. Для этой цели следует изготовить патч, при наложении которого проблема исправляется. Либо если исходники локальные, то править Makefile не в самом optware, а там откуда он их берет.

  7. #7

    Речь об удобстве инструмента

    Quote Originally Posted by al37919 View Post
    в optware исходники править не полагается. Для этой цели следует изготовить патч, при наложении которого проблема исправляется.
    Угу, не спорю. Но для отладки ведь это не удобно, правда?
    Мыслить patch-файлами я пока не научился...
    Last edited by ryzhov_al; 23-12-2010 at 08:30.

  8. #8
    Quote Originally Posted by Zyxmon View Post
    Я в основном подравлял готовые пакеты.
    А я - нет
    Quote Originally Posted by Zyxmon View Post
    Ну а что и когда убивается - логика Makefile такая.
    Поэтому и не удобна мне эта логика.
    Quote Originally Posted by Zyxmon View Post
    strip в optware делается автоматически при сборке ipk.
    Делается для всех пакетов один - самый безопасный. В моём примере:
    • 94КБ - бинарник после компиляции,
    • 70КБ - бинарник после stip'a средствами Optware,
    • 44КБ - бинарник, который я "обтёсывал" strip'ом сам.

    Просто не хочется быть обезъяной с пучком чужих скриптов. Результат всегда лучше, когда процессом руководишь ручками. Лучше всего:
    1. проанализировал работу тулчейна optware,
    2. взял на вооружение механизмы его работы,
    3. дальше делай всё сам(!). И со своим стилем работы.

    Уж если понадобится обнародовать сырцы после допиливания - патчи diff'ами наклепать можно быстро.
    Last edited by ryzhov_al; 23-12-2010 at 08:29.

  9. #9
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ryzhov_al View Post
    [*]Старый тулчейн Олега. gcc 4.1.1(?) + uClibc 0.9.19. В качестве инструмента не рассматриваю, он устарел.
    gcc 3.2.3

    На сайте прошивки есть два архива - hndtools-mipsel-uclibc-4.3.5-2.tar.bz2 и появившийся несколько дней назад hndtools-mipsel-uclibc-4.3.5-x86_64-3.tar.bz2.
    Как легко догадаться, второй только для 64-битной системы. Свежий 32-битный выложит theMIROn, как сможет. Кросс-сборку 32-битного тулчейна на 64-битном хосте я еще не допилил, всё времени не хватает...

    Кросс-компиляция тулчейном энтузиастов.
    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
    ...
    Стандартные пути (/home/al/newtoolchain/lib/gcc/mipsel-linux-uclibc/4.3.5) не нужно включать, они подцепляются сами.

    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
    В чём засада?
    Скорее всего, придётся пересобрать и libpcap под нашу uClibc. Различие в конфиге - у нас выключено UCLIBC_HAS_LOCALE.
    Last edited by lly; 22-12-2010 at 07:57.

  10. #10
    Quote Originally Posted by lly View Post
    Следует заметить, что весь optware'вский софт должен использовать свою версию uClibc.
    Значит, лучше не выделываться и собирать софт с помощью тулчейна optware. В противном случае нельзя будет использовать наработки optware.
    Энтузиастский тулчейн оставить в покое и использовать только для сбора прошивки.

  11. #11
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ryzhov_al View Post
    Значит, лучше не выделываться и собирать софт с помощью тулчейна optware. В противном случае нельзя будет использовать наработки optware.
    Энтузиастский тулчейн оставить в покое и использовать только для сбора прошивки.
    В зависимости от твоих целей. Я всегда пересобираю из исходников нашим тулчейном
    Взять хотя бы до сих пор неустранённые грабли с PIE бинарниками в optware (см. мои сообщения о баге в binutils)...

    Если очень хочется бинарной совместимости с optware uClibc, надо наш тулчейн пересобирать с uClibc 0.9.29 и бекпортить пару пудов патчей из 0.9.30.1

    Ну или спортировать фиксы в optware'вский тулчейн.
    Last edited by lly; 22-12-2010 at 10:07.

  12. #12
    причем второе гораздо кошернее
    p.s. тулчейн x86 постараюсь сегодня выложить

  13. #13
    Quote Originally Posted by ryzhov_al View Post
    Значит, лучше не выделываться и собирать софт с помощью тулчейна optware. В противном случае нельзя будет использовать наработки optware.
    Энтузиастский тулчейн оставить в покое и использовать только для сбора прошивки.
    наш тулчейн, помимо того, что озвучил lly позволяет использовать софт без optware, совсем.
    с другой стороны, если есть куча зависимостей - их проще решать через optware

  14. #14
    Quote Originally Posted by theMIROn View Post
    наш тулчейн, помимо того, что озвучил lly позволяет использовать софт без optware, совсем.
    Как? Статической линковкой?
    Quote Originally Posted by theMIROn View Post
    с другой стороны, если есть куча зависимостей - их проще решать через optware
    Получается так:
    • при малом числе зависимостей лучше собирать новым тулчейном, перекомпилировав зависимости. Результат слинковать статически.
    • если зависимостей много и пересобирать их задача нетривиальная, то лучше использовать тулчейн optware.

    Так? Значит, от optware'овского тулчейна мне никуда не деться и вопрос выбора тулчейна закрыт


    Кстати говоря, а чем присутствующие собирают ipk-пакет после компиляции? На www-просторах для этих целей есть куча самых разнообразных shell-скриптов. Тот, который использую я, имеет косяк в заполнении поля Description. Если в optware'овском тулчейне такой скрипт есть, то этот вопрос то же закрыт.
    Last edited by ryzhov_al; 22-12-2010 at 13:04.

  15. #15
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ryzhov_al View Post
    Как? Статической линковкой?
    зачем??? не выставляй LD_LIBRARY_PATH=/opt/lib и библиотеки из /lib найдутся сами. Ну можно добавить контрольный выстрел - rpath
    Кстати говоря, а чем присутствующие собирают ipk-пакет после компиляции?
    Ну например http://wl500g.googlecode.com/svn/ipk...es/ipkg-utils/

Page 1 of 6 123 ... LastLast

Similar Threads

  1. Entware - новый репозиторий для роутеров Asus (MIPS)
    By ryzhov_al in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 1391
    Last Post: 04-01-2021, 21:16
  2. Переход на летнее время - проблема с timezone
    By ABATAPA in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 101
    Last Post: 22-12-2014, 11:45
  3. Кросс-компиляция rTorrent
    By al37919 in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 94
    Last Post: 22-04-2012, 19:48

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •