Могу ли я использовать chroot на своей машине разработки для сборки приложения, работающего на встроенной установке Linux?

Могу ли я использовать chroot на своей машине разработки для сборки приложения, работающего на встроенной установке Linux?

Я пытаюсь разработать приложение для запуска на встроенной установке Linux. Она поставляется с более старой версией libc, чем та, что есть на моей машине разработки. Если бы я создал среду chroot на своей машине разработки, скопировал библиотеки с моего встроенного устройства таким образом, чтобы среда chroot отражала устройство, а затем собрал приложение, было бы безопасно запускать его на устройстве? Моя машина разработки и устройство — оба x86 32-битные, поэтому я не думаю, что мне нужна кросс-компиляция.

Кроме того, если приложение, которое я пишу, требует привязки к дополнительным библиотекам (которых нет на устройстве), могу ли я безопасно собрать эти библиотеки на машине разработчика в chroot, а затем просто скопировать их на устройство для развертывания приложения?

Из всего прочитанного мной по этой теме следует, что единственный способ гарантировать, что все правильно скомпонуется, — это фактически собрать приложение на устройстве, но это не вариант, поскольку это минимальная установка, которая не входит в установку gcc.

решение1

Это обычно работает. Я бы просто попробовал, но есть несколько вещей, о которых вам нужно знать:

  • При сборке двоичные файлы должны быть собраны для архитектуры ЦП и возможностей вашей целевой системы. Учитывая, что они оба x86, это очень поможет, но вам все равно нужно быть осторожным с использованием функций процессора, таких как sse3 и т. д. Если вы соберете двоичный файл, который использует функции, отсутствующие в вашей целевой установке, он не будет работать.

  • Ядро вашей системы сборки может оказывать некоторое влияние на поведение вашей chroot-среды. Вы не можете использовать другое ядро ​​для chroot-среды по сравнению с хост-системой, поэтому вы можете столкнуться с расхождениями между ними. Однако приложения в конечном итоге обычно взаимодействуют с ядром через libc, которая предоставляет стандартный интерфейс, помогающий предотвратить такие проблемы.

  • Ваша libc должна быть совместима с вашим ядром, в некоторой степени. Libc из вашей встроенной системы может быть не полностью совместима с вашим ядром, в зависимости от изменений интерфейса; однако, если libc предшествует вашему ядру, это вряд ли будет проблемой (старые интерфейсы ядра, скорее всего, останутся для поддержки старых двоичных файлов).

  • Службы вашей хост-системы будут видны вашей встроенной системе. Это обычно для любого chroot, поскольку они совместно используют таблицы процессов, сетевые интерфейсы и т. д.

  • Для ваших «дополнительных библиотек» вы можете использовать статическую компоновку, чтобы связать их с вашим приложением. Тогда вы сможете избежать развертывания библиотек на устройстве. Ваш пробег может отличаться.

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

Имейте в виду, что если вы настраиваете цепочку инструментов сборки внутри chroot, вам, возможно, захочется подумать о том, как вы будете копировать новые файлы обратно во встроенную систему; вы, вероятно, не захотите копировать файлы цепочки инструментов (gcc и т. д.).

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

Связанный контент