Page 2 of 10 FirstFirst 1234 ... LastLast
Results 16 to 30 of 143

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

  1. #16
    Quote Originally Posted by Zyxmon View Post
    Quote Originally Posted by ryzhov_al View Post
    Кстати говоря, а чем присутствующие собирают ipk-пакет после компиляции?
    Если используете optware, то все просто
    Code:
    make mypackage-check
    Разобрался. Только по канонам optware-тулчейна:
    Code:
    $ make mypackage-ipk
    Не забыв перед эти собрать сами скрипты сборки ipk-пакета:
    Code:
    $ make ipkg-utils

  2. #17
    Про make ipkg-utils вроде как написано "в канонах".
    Я написал в свое время такую инструкцию-пересказ канонов

    http://www.synology-forum.ru/wiki/in...BE%D0%BF%D0%B5

    Это не для mipsel, но значения не имеет.
    Из дисрибутивов, чтобы напильником не работать, под которым все собирается остался debian 5.

  3. #18

    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 08:15.

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

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

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

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

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

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

  6. #21
    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 09:29.

  7. #22

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

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

  8. #23

    кросскомпиляция tinc

    Собираю tinc на debian5 в colinux.
    Использую http://svn.nslu2-linux.org/svnroot/optware/trunk
    Одна из зависимостей - openssl - установлена в debian, также её скомпилировал в тулчейне
    Подскажите, чего не хватает:
    Code:
    checking openssl/pem.h usability... yes
    checking openssl/pem.h presence... yes
    checking for openssl/pem.h... yes
    checking openssl/engine.h usability... yes
    checking openssl/engine.h presence... yes
    checking for openssl/engine.h... yes
    checking for SHA1_version in -lcrypto... no
    configure: error: OpenSSL libraries not found.
    make: *** [/home/user/optware/oleg/builds/tinc/.configured] Error 1
    colinux:/home/user/optware/oleg#

  9. #24
    Ищите причину. Всё собирается автоматом, вплоть до пакета.

    Quote Originally Posted by Colibri View Post
    Собираю tinc на debian5 в colinux....
    Одна из зависимостей - openssl - установлена в debian
    Дебиановская библиотека в кросс-компиляции не должна участвовать.
    ./configure скорее всего не находит интерфейсные файлы *.h библиотеки openssl.
    Last edited by ryzhov_al; 29-03-2011 at 21:36.

  10. #25
    ryzhov_al
    Спасибо! Теперь получилось. В основном благодаря .mk-файлу, в нем оказались некоторые неочевидные для меня вещи.

  11. #26
    Я на эти не очевидные вещи тоже целый вечер убил.

    Кстати, я забыл в tinc.mk указать ещё одну зависимость. Если будете где-то выкладывать пакет, не забудьте указать:
    Code:
    TINC_DEPENDS=openssl,lzo
    вместо
    Code:
    TINC_DEPENDS=openssl
    (!) На роутере всесторонне бинарник в работе не проверял. Просто убедился в том, что он не валится в segfault.
    Last edited by ryzhov_al; 07-01-2011 at 16:24.

  12. #27
    Quote Originally Posted by ryzhov_al View Post
    Кстати, я забыл в tinc.mk указать ещё одну зависимость. Если будете где-то выкладывать пакет, не забудьте указать:
    Code:
    TINC_DEPENDS=openssl,lzo
    (!) На роутере всесторонне бинарник в работе не проверял. Просто убедился в том, что он не валится в segfault.
    И еще там zlib в зависимостях.

    Я сгенерировал на роутере ключи и подключился к существующей сети - работает.

  13. #28

    Exclamation Речь об энтузиастком тулчейне

    Есть предложение унифицировать размещение файлов, собранных энтузиастким тулчейном (gcc 4.3.5 uClibc 0.9.30.1). Файлы предлагаю записывать по следующим путям:
    • /opt/1.9.2.7/bin
    • /opt/1.9.2.7/lib
    • /opt/1.9.2.7/include

    Что позволит:
    а) развязать библиотеки, собранные тулчейном optware и новым тулчейном,
    б) автоматизировать сборку libtool'ом, используя ./configure --prefix=/opt/1.9.2.7/,
    в) пользоваться совместными наработками, ссылаясь в своих проектах на указанные пути.

    Конкретизировать в пути "/opt/1.9.2.7-d/" или "/opt/1.9.2.7-rtn/" считаю избыточным, также считаю, что путь "/opt/1.9.2.7/" со старой олеговской прошивкой ассоциироваться не будет. Да и вряд ли кто станет использовать устаревший тулчейн тех времён.

  14. #29

    Question Как правильно указывать пути к своим библиотекам?

    При сборке с помощью энтузиасткого тулчейна есть необходимость использования собственных библиотек, лежащих в /opt/1.9.2.7/lib. Какие ключи необходимо использовать при линковке для того, чтобы по умолчанию библиотеки искались в папке /lib, а затем в папке /opt/1.9.2.7/lib?

    Насколько я понял, optware жестко прописывает пути к библиотекам в /opt/lib
    Code:
    LDFLAGS=" -L/optware/staging/opt/lib -Wl,-rpath,/opt/lib -Wl,-rpath-link,/optware/staging/opt/lib "
    поэтому решение по аналогии не подойдёт. После прописывания rpath на /opt/1.9.2.7/lib библиотеки перестанут искаться в /lib.

    Пока для сборки новым тулчейном использую ключи, нагло спёртые у тулчейна optware
    Code:
    $ cat /media/projects/mk_new.sh
    #!/bin/sh
    AR=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-ar \
    AS=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-as \
    LD=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-ld \
    NM=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-nm \
    CC=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-gcc \
    CPP="/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-gcc -E" \
    GCC=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-gcc \
    CXX=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-g++ \
    RANLIB=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-ranlib \
    STRIP=/media/brcm/hndtools-mipsel-uclibc-4.3.5/bin/mipsel-uclibc-strip \
    CPPFLAGS="-O2   -pipe  -I/media/projects/staging/opt/1.9.2.7/include " \
    LDFLAGS=" -L/media/projects/staging/opt/1.9.2.7/lib " \
    ./configure \
    --build=i386-pc-linux-gnu \
    --host=mipsel-linux \
    --target=mipsel-linux \
    --prefix=/opt/1.9.2.7 \
    --disable-nls \
    --disable-static

  15. #30
    Join Date
    Nov 2006
    Location
    Russia, Moscow
    Posts
    3,640
    Quote Originally Posted by ryzhov_al View Post
    Есть предложение унифицировать размещение файлов, собранных энтузиастким тулчейном (gcc 4.3.5 uClibc 0.9.30.1). Файлы предлагаю записывать по следующим путям:
    • /opt/1.9.2.7/bin
    • /opt/1.9.2.7/lib
    • /opt/1.9.2.7/include
    Предложение интересное, за исключением того что 1.9.2.7 мне не особо нравится.

    Реально разделять нужно только библиотеки, include вообще неактуальны на роутере, так как у нас нет нативного компилятора(аналог buildroot). Выделять bin я тоже не вижу смысла.

    После прописывания rpath на /opt/1.9.2.7/lib библиотеки перестанут искаться в /lib.
    Неправильно, посмотри описание ld. Это всего-лишь первый пункт в списке путей. Ну и иметь несколько путей в rpath никто не запрещает.

Page 2 of 10 FirstFirst 1234 ... LastLast

Similar Threads

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