Jump to content
    

Как влияют системные утилиты на кросс-компиляцию (на примере buildroot)

Приветствую!

Вопрос к знатоками, как влияют системные утилиты для разработки host машины на кросс-компиляцию под ARM?

Ситуация следующая.

Имеется устройство на ARM Cortex-A9, для него есть проверенная сборка на buildroot 2020.x, которую спустя несколько лет возникла необходимость собрать заново. Какая ОС и версии компиляторов использовались при разработке изначально не известно. Попытка собрать этот дистрибутив на моей машине (ubuntu 22.04 последней версии) успехом не увенчалась. Начались проблемы при сборке нескольких пакетов, эту проблему решил путем обновления последних до более новых версий. Затем начались проблемы при сборке qt5 (+gui с eglfs). Первым начал ругаться компилятор с ошибками типа «error: ‘numeric_limits’ is not a member of ‘std’», проблема оказалась распространенной и решилась редактированием исходников qt5 путем добавления заголовочных файлов. Затем начал ругаться линкер, что не может найти библиотеку libGLESv2.so, которая в свою очередь лежит в паке sysroot. В этой же папке лежат библиотеки libpthread.so и т.д., которые он прекрасно видит. Двухдневный поиск решения проблемы не дал результатов. Выяснил только, что есть отдельная переменная QMAKE_LIBDIR_EGL, но как ее настроить не понятно и надо ли вообще ее трогать.

В итоге проблему решил следующим образом. Запустил в docker образ старой версии ubuntu, установил в него все необходимые зависимости, пробросил эту же паку buildroot (предварительно очистив сборку и откатив все свои изменения) и запустил make из docker контейнера. В результате все собралось с первого раза.

Теперь я не могу понять как так, версия toolchain (arm-buildroot-linux-gnueabihf), компиляторов, библиотек и самого buildroot (за исключением нескольких правок с заголовочными файлами) точно такая же как при сборе без docker.

Что может влиять кросс-компилятор? Может это связано с тем, что сам собирается с использованием разных инструментов или есть еще что-то?

Share this post


Link to post
Share on other sites

1 hour ago, Sverchok said:

Что может влиять кросс-компилятор? Может это связано с тем, что сам собирается с использованием разных инструментов или есть еще что-то?

Да много там разных инструментов, не только кросскомпилятор. У каждого инструмента может быть свой набор библиотек даже для одного и того же дистрибутива системы.

Эту проблему пытаются решить очень давно, те же autoconf/automake например, но, имхо, безуспешно. Всегда приходится возиться, чтобы собрать какой-то не мейстримовый пакет (старый, малопопулярный и т.п)

Постоянно появляются какие-то модные-современные сборщики - cargo, sbt, bazel ... это только на той неделе столкнулся, а так их сотни

Практически, чтобы на xосте сборщик увидел динамическую библиотеку, в баше надо сказать (это должно быть в первой выдаче гугля, помоему)

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:_my_path_

upd:  libGLESv2.so может быть линком, а самой библиотеки может и нету. Я билдрут очень давно использовал, контретных деталей не помню

Share this post


Link to post
Share on other sites

1 час назад, yes сказал:

upd:  libGLESv2.so может быть линком, а самой библиотеки может и нету. Я билдрут очень давно использовал, контретных деталей не помню

Да это действительно линк на другую библиотеку, но она тоже есть.

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

Share this post


Link to post
Share on other sites

On 9/26/2024 at 12:24 PM, Sverchok said:

Что может влиять кросс-компилятор?

кроме компилятора целая операционная система на сборочном хосте, buildroot для повторяемости сборок собирает своё системное окружение, посмотрите ради интереса после сборки

ls -d output/build/host*

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

Share this post


Link to post
Share on other sites

9 часов назад, sasamy сказал:

ls -d output/build/host*

Да я смотрел эту папку, тем более что в ней находится sysroot  с библиотеками и собственно сам кросс-компилятор. Единственное отличие в названии тех самых злополучных библиотек: под ubuntu 20.04 это один файл libGLESv2.so{,.2,.2.0}, а под docker три файла libGLESv2.so, libGLESv2.so.2, libGLESv2.so.2.0. Попытка переимоновать результат не дала. Версия компилятора и линкера совпадают.

Видимо есть какая-то host утилита, типа pkg-config, которая учавствует в сборке. Посмотрел бегло в папке buildroot/package/qt5 конфиграцию для пакета qt для версии 2020.х и версии 2024.х, и каких то значительных изменений не увидел.

Share this post


Link to post
Share on other sites

On 9/26/2024 at 12:24 PM, Sverchok said:

...как влияют системные утилиты для разработки host машины на кросс-компиляцию под ARM?...

 

если пром. вариант сборки - никак от слова совсем. Нет любительских комбайнов типа ёкты или билдрута, всё фиксировано - все исходники всех версий есть, есть скрипты которые это собирают, всё это зафиксировано версионно и возможно пересобрать хоть через 200 лет, как отдельно взятый бинарь так и всё целиком.

с уважением
(круглый)

ЗЫ
Так называемые проблемы невозможности повторить, обычно следуют из не прозрачности процесса, скрытой автоматизации, использование пред подготовленных исходников (а не чистых), не доработки (не профессионализм) разработчиков которые это запускали в проект.

Edited by kolobok0

Share this post


Link to post
Share on other sites

On 9/28/2024 at 4:47 PM, kolobok0 said:

Нет любительских комбайнов типа ёкты или билдрута, всё фиксировано - все исходники всех версий есть, есть скрипты которые это собирают, всё это зафиксировано версионно и возможно пересобрать хоть через 200 лет, как отдельно взятый бинарь так и всё целиком.

версии зафиксировать можно и в ёкте и в буилдруте - берёте релиз и не меняете версии, исходники локально сохраняются и там и там. А насчёт профессионалов.. ну расскажите им как вы скриптиками рынок промышленных линуксов захавали 🙂

https://www.yoctoproject.org/members/

 

Share this post


Link to post
Share on other sites

On 9/26/2024 at 12:24 PM, Sverchok said:

что не может найти библиотеку libGLESv2.so,

Для нормальной работы с LibGLES на кроссе надо патчить .cmake файлы из комплекта Qt (FindGLESV2.cmake и FindEGL.cmake), они там написаны левой задней ногой...

Share this post


Link to post
Share on other sites

В 29.09.2024 в 11:15, gosha-z сказал:

Для нормальной работы с LibGLES на кроссе надо патчить .cmake файлы из комплекта Qt (FindGLESV2.cmake и FindEGL.cmake), они там написаны левой задней ногой...

Спасибо за подсказку я попробую глянуть.

Share this post


Link to post
Share on other sites

On 9/29/2024 at 2:11 AM, sasamy said:

версии зафиксировать можно и в ёкте и в буилдруте ...

 

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

 

(круглый)

Share this post


Link to post
Share on other sites

В 26.09.2024 в 14:24, Sverchok сказал:

В итоге проблему решил следующим образом. Запустил в docker образ старой версии ubuntu, установил в него все необходимые зависимости, пробросил эту же паку buildroot (предварительно очистив сборку и откатив все свои изменения) и запустил make из docker контейнера. В результате все собралось с первого раза.

Я столкнулся с такой же проблемой. Поставщик модуля поставил систему сборки основанную на buildroot. Система сборки на скриптах (аля lichee). В мануале перечень программ, для рабочего окружения хоста. В том числе и хостовый нативный gcc.  Всё это под Ubuntu18. Я запустил на виртуалке Ubunti24 - не собралось. Началось с того, что в сборке есть код для phyton2, а дефолтный в U24 - phyton3. КОД ПИТОН2 НЕ РАБОТАЕТ В ПИТОН3!!! На следущем этапе квеста ругонь от компилятора gcc 13. Что-то там в исходниках ему не понравилось. Поправил исхоодник, далее новая трабла с gcc, гуглелние дало откат на gcc 9. Откатил gcc. Потом откат какой-то библиотеки на более старую версию, потом другой, потом парачка... замучался. Поставил в виртуалку Ubuntu 22, взял чистую сборку и  - build config && build && build pack - всё собралось с первого раза. В рабочей Ubuntu 22 нажал кнопку "Udpate to Ubuntu 24" - обновился до 24, запускаю сборку - и всё теже траблы: Питон, gcc, библиотеки.... Вернулся в 22.

Я тоже думал, что хост не должен влиять на кросскомпиляцию. Имея my_defconfig - в котором указан (пусть будет локальный архив) конкретное ядро линукс и конкретное системное кружение для таргета - на любом ПК, через 200 лет, должно всё собраться. Ошибался. 

 

Пока я плохо вижу пути решения проблемы. 1) - сделать виртуалку с ubuntu 18 + окружение и через 200 лет в виртуалке пересобирать. Но, через 200 лет нет гарантии, что моя виртуалка, созданная в VirtualBox 7.0 запустится в VirtualBox 11.2, или сама  VirtualBox 7.0 установится в Windows 42. Уже есть печальный опыт в новой винде на новой виртуалке открыть старую ВМ. 

2) Докер - выглядит по привлекательней, но тоже нет гарантии, что старый сегодняшний докер будет работать через 200 лет.

В 27.09.2024 в 04:23, sasamy сказал:

через несколько лет этих исходников и на зеркалах может не оказаться

и с этим я столкнулся. в buildroot в my_defconfig было указано ядро custom git и ссылка куда-то на патченое ядро в ресурсах freescale. Через пару лет ссылка не работает, на сайте хранилища freescale этого ядра больше нет. Благо дело случайно осталась локальная копия архива. 

Edited by ericN

Share this post


Link to post
Share on other sites

On 10/1/2024 at 7:07 AM, ericN said:

Но, через 200 лет нет гарантии, что моя виртуалка, созданная в VirtualBox 7.0 запустится в VirtualBox 11.2, или сама  VirtualBox 7.0 установится в Windows 42. Уже есть печальный опыт в новой винде на новой виртуалке открыть старую ВМ. 

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

On 10/1/2024 at 7:07 AM, ericN said:

Докер - выглядит по привлекательней, но тоже нет гарантии, что старый сегодняшний докер будет работать через 200 лет.

а сегодня вы соберете buildroot в докере на венде ?

On 9/30/2024 at 11:59 PM, kolobok0 said:

Но для пром. варианта, когда работают над проектом десятки людей - это не вариант.

как раз вариант чтобы не содержать десятки макак нахлебников которые вместо разработки занимаются пересборкой

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...