Erstellen von Linux-Binärdateien für mehrere Plattformen

Question

Helfen Sie mir, eine Punktzahl zu begleichen.

Ich habe ein Stück Software in C++ geschrieben, die auf so viele Linux-Distributionen wie möglich laufen soll und ich muss eine Strategie finden, die effektiv ist. Ich versuche, Binärdateien in diesem Fall nicht Quellcode (möglicherweise gut zu wissen) zu versenden. Es ist bereits ein kommerzielles Produkt und ich habe Probleme mit dem geistigen Eigentum, die mich daran hindern, das Produkt zu beschaffen, sondern auch, dass ich mich mit einer Vielzahl von GPL-Problemen auseinandersetzen muss.

Die aktuelle Argumentationslinie bestand darin, einen kleinsten gemeinsamen Nenner zu wählen und daraus alles aufzubauen. Das hat zwei wichtige Auswirkungen, die ich kontraproduktiv finde.

1. Die C++ - Unterstützung in alten Versionen von GCC fehlt einige modernere C++ - Funktionen.
2. Der kleinste gemeinsame Nenner bringt Red Hat Enterprise Linux 4 (RHEL4)

ich definitiv nicht brauchen, die die gesamte C++ 11 Feature-Set, aber ich möchte die C++ unterstützen, dass bis bringen von Visual C++ 2010. Ich lese die Idee, Clang/libC++ im Gegensatz zu GCC/libstdC++ wo möglich zu verwenden.

RHEL4 scheint keine umfassende plattformübergreifende Unterstützung für die Erstellung von C++ - Anwendungen zu haben. Ich habe wenig Einblick in die Stabilität von ABI über verschiedene Versionen von Linux, aber ich bin besorgt, dass RHEL4 mehr Mühe als wert ist. Der Versuch, für alle Distributionen basierend auf wenigen zu bauen, ist keine praktikable Strategie.

Ich gehe davon aus, dass Kompilieren von Software für verschiedene Linux-Distributionen am besten durch Kompilieren der Software für die Zielplattform mit Tools auf der Zielplattform erreicht wird. Ich gehe derzeit auch davon aus, dass es bei Linux-Plattformen zu Problemen mit der Portabilität kommt, wenn Sie das nicht akzeptieren. Um nicht über die vielen Bibliotheken zu sprechen, mit denen Sie aufgrund von C++ - ABI-Instabilität plattformübergreifend/verteilbar sein können oder nicht.

Aber ich könnte falsch liegen, ich würde gerne von den Leuten hören, die sich regelmäßig damit beschäftigen. Was wird funktionieren und warum? oder wichtiger, was wird nicht funktionieren?

Answer 1

Sie können versuchen, auf eine konzentrieren wenige größere Plattformen als einzelne Distributionen. Was ich damit meine, ist, auf etwas aufzubauen, was ich die "grundlegenden Distributionen" (Debian und RedHat) nenne, und hoffe auf das Beste bei den anderen.

Höchstwahrscheinlich werden Debian-Binärdateien (die statisch verknüpft sind) auf Ubuntu und Mint und anderen von Debian abgeleiteten Distributionen einwandfrei funktionieren. RedHat-Binärdateien werden wahrscheinlich auf Centos, Scientific Linux und SuSE Linux laufen. Wenn Sie sich für weniger beliebte Distributionen interessieren (sagen Sie, dass viele Kunden ein ungewöhnliches Linux ausführen) und weder Ihre Debian- oder RedHat-Programmdatei funktioniert noch irgendwie funktioniert, dann richten Sie eine VM dieser Distribution ein und erstellen Sie eine ausführbare Datei speziell für diesen Geschmack.

Ich habe diesen Ansatz in der Vergangenheit genommen und es hat gut funktioniert.

Answer 2

Der beste Weg, dies zu tun, um Ihre Software einige Open-Source-free software (z. B. GPLv3 + Lizenz), dann wenn Ihre Software interessant genug ist, wird es in Distributionen verpackt (durch die Verteilung Betreuer).

Sie möchten immer Verteilungspakete (z. B. .deb Dateien für Ubuntu oder Debian) bereitstellen, da diese am einfachsten zu installieren sind.

Wenn Sie noch proprietäre Software machen wollen (aber sich fragen, ob Sie in der Lage sein wird, zu verkaufen, oder sogar gratis verteilen, erfolgreich Software), könnten Sie die folgenden Schritte ausführen:

• Kompilieren Sie einen aktuellen GCC-Compiler (zB 4.8), indem Sie eine statische stdC++ & eine statische libgcc aktivieren (die meisten bereitgestellten Distributionen GCC tun dies nicht).

• verknüpfen Sie Ihr Programm möglicherweise statisch (aber Sie können dies möglicherweise nicht tun, zum Beispiel für /etc/nsswitch.conf verwandte Funktionen, einschließlich getaddrinfo und verwandte DNS-Dienste).

Selbst durch alle C Verknüpfung ++ bezogenes statisch ab, die Sie immer noch auf libc.so.6 und dann können Sie einige NYS Versionierung Probleme haben (also eine binäre für eine libc-Version kompiliert 2.17 wird nicht immer mit einem libc laufen 2,16 oder und umgekehrt). Beachten Sie auch, dass GNU libc normalerweise an eine Kernel-Version gebunden ist (Sie können keine neuere libc in einem ziemlich alten Kernel verwenden). Sie könnten einige alternative libc wie MUSL libc

betrachten BTW, in der Regel Sie einige chroot -ed Zielumgebung verwenden können (in dem Sie vielleicht eine andere Verteilung installieren, z. B. mit debootstrap)

Answer 3

Wenn jemand neugierig ist, haben wir das Problem gelöst, indem wir eine GCC 4.8 Toolchain auf einem RHEL 4.8 dist erstellt haben, die weiterhin unser Build Agent war.

Der Kernpunkt ist umrissen here. Das Problem war ein wenig einfacher, da wir keinen voll funktionsfähigen Cross-Compiler benötigen. Nur eine GCC 4.8 Toolchain auf dem Ziel-Host.

Interoperabilität war immer noch ein Schmerz, weil diese alte Version von Linux praktisch keine Unterstützung für SMB und/oder andere Tech hatte. Am Ende hatten wir ein Bash-Skript, das Build-Ausgaben in einen FTP-Server brachte und das funktionierte einigermaßen gut. Es löste große Schmerzen.