Чи працює мій бінарний Linux на всіх дистрибутивах?

Я знайшов хорошу заміну IDE для Delphi під назвою Lazarus. Але я не маю запитання до програмістів.

Чи буде статично пов’язаний бінарний диск Linux працювати на всіх дистрибутивах Linux? Тобто не має значення, на якому дистрибутиві Linux я його побудував, і він буде працювати на Debian / ArchLinux / Ubuntu / OpenSUSE / ... що завгодно?

Як результат моїх висновків, чи дійсно має значення лише 32-бітний проти 64-бітний? Я хочу бути впевненим, перш ніж публікувати.

Ця відповідь спочатку була написана на більш загальне запитання "чи буде бінарний файл працювати на всіх дистрибутивах", але він стосується статично пов'язаних двійкових файлів у другій половині.

На все, що складніше, ніж статично пов'язаний світ привіт, відповідь, мабуть, "ні" .
Без тестування на розподіл X, не брати до уваги , що відповідь є не для X.

Якщо ви хочете відправити своє програмне забезпечення у двійковій формі, обмежтеся

• кілька популярних дистрибутивів у галузі використання вашого програмного забезпечення (настільний, серверний, вбудований, ...)

• останню одну-дві версії кожної

Інакше у вас з’являються переслідувачі різного розміру, версії та віку (десятирічна дистрибуція все ще використовується та підтримується).

Тест на те. Всього кілька покажчиків того, що може (і буде) піти не так:

• Пакет потрібного інструменту / бібліотеки названий по-різному в різних дистрибутивах і навіть версіях одного дистрибутива

• Бібліотеки, які вам потрібні, занадто нові або занадто старі (неправильна версія). Не припускайте лише тому, що ваша програма може зв’язуватися, вона посилається на потрібну бібліотеку.

• Одна і та ж бібліотека (файл на диску) по-різному називається в різних дистрибутивах, що робить зв'язок неможливим

• 32 біт на 64 біт: 32-бітове середовище може бути не встановлено, або якась несуттєва 32-бітна бібліотека переміщена в додатковий пакет, крім середовища 32on64, тому у вас є додаткова залежність саме для цього випадку.

• Shell: не припускайте свою версію Bash. Не припускайте навіть Баша.

• Інструменти: не припускайте, що якийсь інструмент командного рядка POSIX не існує де-небудь.

• Інструменти: не припускайте, що інструмент розпізнає варіант лише тому, що це версія GNU вашого дистрибутива.

• Інтерфейси ядра: Не припускайте існування та структури файлів /procлише тому, що вони існують / мають структуру на вашій машині

• Java: Ви дійсно впевнені, що ваша програма працює на JRE IBM як постачається зі SLES, не тестуючи її?

Бонус:

• Набори інструкцій: двійковий файл, зібраний на вашій машині, не працює на старішому апаратному забезпеченні.

Чи є з'єднання статичним (або: поєднання всіх необхідних бібліотек із вашим програмним забезпеченням)? Навіть якщо це працює технічно, пов'язані з цим витрати можуть бути високими. Тож, на жаль, відповіді, мабуть, теж немає.

• Безпека: ви перекладаєте відповідальність за оновлення бібліотек з користувача свого програмного забезпечення на себе.

• Розмір і складність: просто для задоволення спробуйте створити статично пов'язану програму GUI.

• Інтероперабельність: якщо ваше програмне забезпечення є будь-яким "плагіном", ви залежите від програмного забезпечення, яке вам дзвонить.

• Дизайн бібліотеки: якщо ви стаціонально пов’язуєте свою програму з GNU libc та використовуєте служби імен ( getpwnam()тощо), ви в кінцевому підсумку динамічно пов’язані проти NSS libc (перемикач служби імен).

• Дизайн бібліотеки: бібліотека, з якою ви стаціонально зв’язуєте свою програму, використовує файли даних або інші ресурси (наприклад, часові пояси або локалі).

З усіх вищезгаданих причин тестування є важливим.

• Ознайомтеся з KVM або іншими методами віртуалізації та отримайте VM кожного дистрибутива, який ви плануєте підтримувати. Тестуйте програмне забезпечення на кожному VM.

• Використовуйте мінімальні установки цих дистрибутивів.

• Створіть VM з обмеженим набором інструкцій (наприклад, немає SSE 4).

• Лише статично пов'язані або в комплекті: перевірте свої файли бінарних файлів, lddщоб перевірити, чи вони дійсно статично пов'язані / використовуйте лише ваші бібліотеки в комплекті.

• Статично лише пов'язані або в комплекті: створити порожній каталог та скопіювати у нього програмне забезпечення. chrootу цей каталог та запустіть програмне забезпечення.

Відповідь - це залежить. , але в більшості випадків так, доки в ОС встановлені необхідні бібліотеки.

Як правило, більшість основних дистрибутивів, як і ті, про які ви згадали, мають свої інструменти управління пакетами, які встановлюють версію програми, що підтримується спільнотою. Це турбується про будь-які обов'язкові пакети, необхідні додатку. Якщо ви встановлюєте його без менеджера пакунків, вам належить переконатися, що всі необхідні пакети та бібліотеки встановлені на ОС. Непогано включити список цих необхідних додатків у документацію.

Перша відповідь хитра: Це залежить

Якщо ви випускаєте бінарні файли, вважайте, що відповідь є "ні", якщо ви не поширюєте всі зв'язки, які вона коли-небудь пов’язана з цим (з нуля, що дратує, якщо ви не забезпечите справді величезну систему, яка так чи інакше стоїть. ) або статично пов'язують еквівалент.

... але чарівники і гроші, і майстри грошей ...

У IBM є кілька «загальних установців Unixish», які мене шокували, працюючи скрізь, де я їх пробував: кілька лінусів декількох поколінь ядер, OpenSolaris (або як його зараз називають), Solaris та BSD. Але вони величезні. І речі, які вони надають, однаково величезні. Ніяких програм з невеликих гоночних автомобілів не публікується таким чином, лише великі підприємства, які ви очікували від IBM.

Що стосується того, що ви просто користуєтеся Linux, але добре працюєте в більшості Linuxdom, це здається можливим у двійковій формі, про що свідчить різноманітність встановлених бінарних установщиків типу "для Linux (загального)", які ви побачите у деяких постачальників. Кілька чатів, браузерів, ігор, метаінсталяторів тощо публікуються таким чином, але завжди величезними постачальниками, які можуть витратити час, щоб отримати це право. Вони начебто дивовижні, що вони можуть сказати "для Linux" і бути впевненими, що це спрацює, але це, мабуть, так і є.

Але ...

Я поширюю своє програмне забезпечення як джерело з утилітою збирання. Я роблю це в C, Erlang, Python, Guile тощо. Це дає мені набагато більшу гнучкість щодо того, буде вона запускатись чи ні, і набагато простіше написати buildscript, який гарантує, що потрібні речі існують під час збирання, ніж переконайтеся, що все на своєму місці під час виконання. Коли це існує, тривіально написати автоматичне оновлення для вашої програми, якщо ви поширюєте джерело: джерело зазвичай набагато менше, ніж двійкове, що включає всі депси та інші божевілля. Використовуючи цей метод, у мене не було особливих проблем з надійним розгортанням у Unices (а іноді і в Windows, але це трохи більше завдання).

Досить дитячої гри, озбройтеся!

Коли ви ставитесь серйозно, як, наприклад, srsly srs, до того, щоб плавно вписатись у світ Linux, ви поширюєте C-джерела або звертаєтесь до повністю керованого середовища для хакерсько-чудової мови, яка вже створена. Наприклад, якщо ви пишете код Python, ви можете перевірити версії та знати, з якою версією CPython працює ваша версія, і, як правило, очікувати існування сумісної версії на даному Linux (і це набагато простіше перевірити, ніж широкий аналіз C libs / версії, які ви можете використовувати). Erlang, Підступність, Python, Perl, CL і т.д., все дуже прості цілі для такого типу розгортання, і багато з них мають центральне сховище, наприклад CPAN або pip (або будь-яке інше), де користувачі можуть запускати команду, щоб самостійно витягнути підписане джерело, коли вони цього захочуть, і знати, що загалом справи працюватимуть так, як ви задумали .

[Додаток: 1. Навіть Haskell в цілому може витягнути це через Кабал - хоча я би з обережністю ставлюся до цього у виробничих умовах. 2. З Erlang існують абсолютно різні стратегії розгортання, які гарантують, що ваш код має повне оточення. 3. Python йде на крок далі з віртуальними середовищами; не всі умови роботи так само допомагають тобі.]

Цей останній шрифт про керовані середовища в Linux є дивним . І, як бонус, він дозволяє визначити набагато більш загальні залежності, дозволити їх автоматично вирішувати без зайвих зусиль з вашого боку, не вимагає написання пакета на дистрибутив, і ви можете перестати дбати про те, чи система 32 чи 64 біт (взагалі, все одно).