Создание бинарных файлов linux для нескольких платформ

Помогите мне уладить счет.

У меня есть программное обеспечение, написанное на С++, которое предназначено для запуска как можно большего количества дистрибутивов Linux, и мне нужно выяснить эффективную стратегию. Я пытаюсь отправить двоичные файлы в этом случае, а не исходный код (может быть, хорошо знать). Это уже коммерческий продукт, и у меня есть проблемы с интеллектуальной собственностью, которые мешают мне открывать источник продукта, но также означают, что мне приходится иметь дело с множеством проблем GPL.

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

  • Поддержка С++ в старых версиях GCC не имеет более современных возможностей С++.
  • Наименьший общий знаменатель включает Red Hat Enterprise Linux 4 (RHEL4)

Мне определенно не нужен весь набор функций С++ 11, но я бы хотел довести поддержку С++ до версии Visual С++ 2010. Я просматриваю идею использования Clang/libС++ в отличие от GCC/libstdС++, где возможно.

RHEL4, похоже, не обладает обширной поддержкой кросс-платформы для создания приложений на С++, более того, я мало разбираюсь в стабильности ABI в разных версиях Linux, но я обеспокоен тем, что RHEL4 больше проблем, чем стоит. Попытка построить для всех дистрибутивов, основанных на нескольких, не является жизнеспособной стратегией.

Я полагаю, что компиляция программного обеспечения для разных дистрибутивов Linux лучше всего выполняется путем компиляции программного обеспечения для целевой платформы с помощью инструментов на целевой платформе. Я также в настоящее время работает в предположении, что вы столкнетесь с огромными проблемами с переносимостью перекрестных Linux-платформ, если не примете это. Не говорить о многих библиотеках, с которыми вы можете или не можете связаться, из-за нестабильности С++ ABI в разных платформах/дистрибутивах.

Но я мог ошибаться, я хотел бы услышать от людей, которые занимаются этим на регулярной основе. Что будет работать и почему? или что еще более важно, что не сработает?

ОТВЕТЫ

Ответ 1

Вы можете попытаться сосредоточиться на нескольких основных платформах, а не на отдельных дистрибутивах. Я имею в виду, что это основано на том, что я называю "основополагающими дистрибутивами" (Debian и RedHat) и надеюсь на лучшее на других.

Скорее всего, двоичные файлы Debian (которые статически связаны) будут отлично работать на Ubuntu и Mint и других дистрибутивах Debian. Бинарные файлы RedHat, вероятно, будут работать на Centos, Scientific Linux и SuSE Linux. Если вы заботитесь о менее популярных дистрибутивах (скажем, у вас много клиентов, работающих с каким-то необычным Linux), и ни ваш исполняемый файл Debian, ни RedHat не работает на них или не может быть каким-то образом работать, затем настройте виртуальную машину этого дистрибутива и создайте один исполняемый файл специально для этого аромата.

Я использовал этот подход в прошлом, и он работал хорошо.

Ответ 2

Лучший способ сделать это, чтобы сделать ваше программное обеспечение свободным программным обеспечением с открытым исходным кодом (например, лицензия GPLv3 +), тогда, если ваше программное обеспечение достаточно интересно, что он будет упакован в дистрибутивы (составителем распространения).

Вы всегда хотите предоставить дистрибутивные пакеты (например, файлы .deb для Ubuntu или Debian), поскольку они проще всего установить.

Если вы все еще хотите создать проприетарное программное обеспечение (но спросите себя, сможете ли вы продать или бесплатно распространить бесплатное программное обеспечение), вы можете сделать следующие шаги:

  • скомпилировать недавний компилятор GCC (например, 4.8), включив статический stdС++ и статический libgcc (в большинстве предоставленных GCC GCC этого не делают).

  • свяжите свою программу, возможно, статически (но вы, возможно, не сможете это сделать, например, для /etc/nsswitch.conf связанных функций, включая getaddrinfo и связанные службы DNS).

Даже связывая все связанные с С++ вещи статически, вы все еще зависите от libc.so.6, а затем у вас могут возникнуть проблемы с версией Gnu Libc (поэтому двоичный файл, скомпилированный для версии libc версии 2.17, не всегда будет работать с libc 2.16 или наоборот). Также обратите внимание, что GNU libc обычно привязан к некоторой версии ядра (вы не можете использовать недавний libc на каком-то довольно старом ядре). Вы можете рассмотреть некоторые альтернативные libc как MUSL libc

Кстати, вы обычно можете использовать некоторую целевую среду chroot -ed (в которой вы можете установить другой дистрибутив, например, с debootstrap)

Ответ 3

Если кому-то интересно, мы решили проблему, создав инструментальную цепочку GCC 4.8 поверх RHEL 4.8 dist, которая продолжала оставаться нашим агентом сборки.

Суть этого описана здесь. Проблема была немного проще, поскольку нам не нужен полностью функциональный кросс-компилятор. Просто привязка GCC 4.8 на целевом хосте.

Взаимодействие по-прежнему было больно, потому что эта старая версия Linux практически не поддерживала SMB и/или другие технологии. Мы закончили с Bash script, которые поместили выходы сборки на FTP-сервер, и это работало достаточно хорошо. Он решил основные боли.