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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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