Sverchok 1 26 сентября Опубликовано 26 сентября · Жалоба Приветствую! Вопрос к знатоками, как влияют системные утилиты для разработки 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. Что может влиять кросс-компилятор? Может это связано с тем, что сам собирается с использованием разных инструментов или есть еще что-то? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 26 сентября Опубликовано 26 сентября · Жалоба 1 hour ago, Sverchok said: Что может влиять кросс-компилятор? Может это связано с тем, что сам собирается с использованием разных инструментов или есть еще что-то? Да много там разных инструментов, не только кросскомпилятор. У каждого инструмента может быть свой набор библиотек даже для одного и того же дистрибутива системы. Эту проблему пытаются решить очень давно, те же autoconf/automake например, но, имхо, безуспешно. Всегда приходится возиться, чтобы собрать какой-то не мейстримовый пакет (старый, малопопулярный и т.п) Постоянно появляются какие-то модные-современные сборщики - cargo, sbt, bazel ... это только на той неделе столкнулся, а так их сотни Практически, чтобы на xосте сборщик увидел динамическую библиотеку, в баше надо сказать (это должно быть в первой выдаче гугля, помоему) export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:_my_path_ upd: libGLESv2.so может быть линком, а самой библиотеки может и нету. Я билдрут очень давно использовал, контретных деталей не помню Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sverchok 1 26 сентября Опубликовано 26 сентября · Жалоба 1 час назад, yes сказал: upd: libGLESv2.so может быть линком, а самой библиотеки может и нету. Я билдрут очень давно использовал, контретных деталей не помню Да это действительно линк на другую библиотеку, но она тоже есть. Я знал, что новые версии компиляторо зачастую могут не собирать старый код, но для меня было открытием, что один и тот же кросс-компилятор ведет себя по разному. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 26 сентября Опубликовано 26 сентября · Жалоба On 9/26/2024 at 12:24 PM, Sverchok said: Что может влиять кросс-компилятор? кроме компилятора целая операционная система на сборочном хосте, buildroot для повторяемости сборок собирает своё системное окружение, посмотрите ради интереса после сборки ls -d output/build/host* но и это не всегда помогает. Докеры это полезно конечно но виртуалка надёжней, кроме того что вендоюзеры могут использовать там еще и локальные копии исходников сохраняются - через несколько лет этих исходников и на зеркалах может не оказаться Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sverchok 1 27 сентября Опубликовано 27 сентября · Жалоба 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.х, и каких то значительных изменений не увидел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 28 сентября Опубликовано 28 сентября (изменено) · Жалоба On 9/26/2024 at 12:24 PM, Sverchok said: ...как влияют системные утилиты для разработки host машины на кросс-компиляцию под ARM?... если пром. вариант сборки - никак от слова совсем. Нет любительских комбайнов типа ёкты или билдрута, всё фиксировано - все исходники всех версий есть, есть скрипты которые это собирают, всё это зафиксировано версионно и возможно пересобрать хоть через 200 лет, как отдельно взятый бинарь так и всё целиком. с уважением (круглый) ЗЫ Так называемые проблемы невозможности повторить, обычно следуют из не прозрачности процесса, скрытой автоматизации, использование пред подготовленных исходников (а не чистых), не доработки (не профессионализм) разработчиков которые это запускали в проект. Изменено 28 сентября пользователем kolobok0 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 28 сентября Опубликовано 28 сентября · Жалоба On 9/28/2024 at 4:47 PM, kolobok0 said: Нет любительских комбайнов типа ёкты или билдрута, всё фиксировано - все исходники всех версий есть, есть скрипты которые это собирают, всё это зафиксировано версионно и возможно пересобрать хоть через 200 лет, как отдельно взятый бинарь так и всё целиком. версии зафиксировать можно и в ёкте и в буилдруте - берёте релиз и не меняете версии, исходники локально сохраняются и там и там. А насчёт профессионалов.. ну расскажите им как вы скриптиками рынок промышленных линуксов захавали 🙂 https://www.yoctoproject.org/members/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 3 29 сентября Опубликовано 29 сентября · Жалоба On 9/26/2024 at 12:24 PM, Sverchok said: что не может найти библиотеку libGLESv2.so, Для нормальной работы с LibGLES на кроссе надо патчить .cmake файлы из комплекта Qt (FindGLESV2.cmake и FindEGL.cmake), они там написаны левой задней ногой... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sverchok 1 30 сентября Опубликовано 30 сентября · Жалоба В 29.09.2024 в 11:15, gosha-z сказал: Для нормальной работы с LibGLES на кроссе надо патчить .cmake файлы из комплекта Qt (FindGLESV2.cmake и FindEGL.cmake), они там написаны левой задней ногой... Спасибо за подсказку я попробую глянуть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 30 сентября Опубликовано 30 сентября · Жалоба On 9/29/2024 at 2:11 AM, sasamy said: версии зафиксировать можно и в ёкте и в буилдруте ... да я вас не отговариваю. просто ёкта и билдрут это для меня уже пройденная булочка. если Вы подумаете и подсчитаете плюсы и минусы данного подхода - то наверное услышите меня. а так - комбайны это не пром. варианты от слова совсем. Это наколеночное, штучное производство - отлично подходит. Но для пром. варианта, когда работают над проектом десятки людей - это не вариант. (круглый) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ericN 3 1 октября Опубликовано 1 октября (изменено) · Жалоба В 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 этого ядра больше нет. Благо дело случайно осталась локальная копия архива. Изменено 1 октября пользователем ericN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 1 октября Опубликовано 1 октября · Жалоба 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: Но для пром. варианта, когда работают над проектом десятки людей - это не вариант. как раз вариант чтобы не содержать десятки макак нахлебников которые вместо разработки занимаются пересборкой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
