Als ich das las war mein erster Gedanke: ach guck,
Kylix ist zurück. Alter Wein in neuen Schläuchen, sozusagen.
Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver.
Wer kennt sich denn mit Linux'en aus ?
Ich sehe 64-Bit Ubuntu im Beispiel als Platform ...
Ist das bei einem Kompilat ohne SO eigentlich egal, das sollte doch auf ALLEN Linux-Derivaten gleich Laufen.
Also wenn nichts spezielles eingebunden wird.
Also wenn die glibc eingebunden wird, kommt es ganz auf den Linker bzw. die Steuerung des Linkers an. Die glibc ist nämlich nur vorwärtskompatibel. Will heißen, daß du ein Programm welches gegen eine neue Version von glibc linkst nicht unbedingt auf einer anderen Distro mit älterer glibc oder derselben Distro aber in älterer Version laufenlassen kannst.
Das kann man, wie geschrieben, steuern. Aber es bringt auch kleine Nachteile mit sich. Dennoch: prinzipiell ist es möglich auch mit einer aktuellen Toolchain Programme zu verfassen die auf uralten Systemen, bspw. 2.6.2er Kernel aufwärts (glibc hängt naturgemäß stark vom Kernel ab), laufen.
Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die
LGPL. Ja, die
LGPL ist hier insofern relevant, weil sie verlangt, daß wahlweise der Quelltext zu eurem Programm mitgeliefert werden muß oder alternativ ihr die Objektdateien mitliefern dürft, damit der Benutzer sie mit einer neuen Version der Bibliothek (bspw. glibc) linken darf.
Man kann mutmaßen, daß die
"GCC Runtime Library Exception" (
FAQ) hier greift, aber eigentlich bezieht sich die ausschließlich auf die libgcc. Aber ihr könnt ja immernoch einen Anwalt anheuern um das ggf. klären zu lassen.
Unter Linux ist statisches Linken eher unüblich, zumal gelinkte Bibliotheken dann die Betriebssystemupdates nicht bekommen würden, aber das ist unter Windows ja sowieso immer der Fall.
Auch nur in den Fällen in denen es auf Linux der Fall ist, wenn wir über statisch gelinkte Bibliotheken reden. Ansonsten kommt es auf die Bibliothek an. Die C Runtime von Visual C++ 6.x wurde irgendwann in den Stand einer Systembibliothek erhoben. Ansonsten obliegt es dir die C Runtime Redistributables mitzuliefern.
Statisch gelinkte Kompilate sollten mit jeder Distribution auf x86/x64 laufen. Die Kernelversion hat vermutlich wenig Einfluss darauf.
Das kommt allein darauf an welche Systemaufrufe (system calls) in der statisch gelinkten Bibliothek Verwendung finden. So pauschal kann man das nicht sagen.
Ach ja und wenn Delphi hier wie der Linker von Binutils im ELF-Header gewisse Hinweise hinterläßt über die Kompatibilität mit dem Kernel, wirkt das auch einschränkend. Ich empfehle einmal
auszuführen und die Ausgabe hier zu zeigen. Das hat Herr Cantu leider versäumt.
Mit Free Pascal und Ubuntu 12.04 / 14.04 Single-Exe Anwendungen hatte ich das Problem, dass wegen einer neueren eingebundenen libc die in Ubuntu 14.04 erzeugte Anwendung nicht auf 12.04 ausgeführt werden kann (anders herum habe ich es nicht getestet).
Ich benutze kein FPC, aber mit GCC läßt sich das relativ einfach umgehen. Es handelt sich genaugenommen nämlich nur um eine Handvoll von Funktionen gegen die auf dem neueren System gelinkt wird, welche in der älteren Bibliotheksversion nicht existent sind. Das ist alles steuerbar.
Wenn FMX auf Linux portiert würde, dann wahrscheinlich, wie gesagt, direkt auf das X11-Protokoll.
Meiner Meinung nach Wunschdenken. Die werden wohl den Weg des geringsten Aufwands gehen. Und das wäre eine existierende Lösung ala Qt. Was dann wiederum eigene Vorteile (aber auch ein paar Nachteile) mit sich brächte.
Das größte Problem wird sein das die Libc-Files nicht konvertiert sind zu Delphi, und wahrscheinlich
auch nicht immer 1:1 oder überhaupt konvertierbar sind.
Wieso? Im Gegenteil, wenn diese Linuxversion direkt auf den Systemaufrufen aufsetzen
würde, wäre dies lizenztechnisch für kommerzielle Anbieter ein nicht zu verachtender Vorteil (s.o.). FPC macht dies ja scheinbar so - siehe Beiträge von Mitdiskutanten weiter oben.
Aber was ich generell nicht verstehe ist wie die verschiedenen Libc-Versionen in Linux organisiert sind.
Auch unter Linux muss alles aus dem gleichen Versionsraum kommen, sonst kracht es da auch.
Ich verweise auf
diese Frage&Antwort. Es gibt da auch ein paar Artikel zum Thema
von Herrn Drepper und einigen anderen.
Gibt es immer mehrere Versionen des Kernels und der Libraries auf jedem System ?
Ich denke das ist eines der Probleme bei Linux, das jede Distribution da alt und neu mischen kann und
auch an anderen Stellen/Bezeichnern ablegen kann.
Leider ist das Problem nicht Linux, sondern dein mangelndes Verständnis
Kernel und libc sind aufeinander bis zu einem gewissen Punkt abgestimmt. Viele der Funktionen aus der C-Laufzeit sind nämlich direkt in Systemaufrufe übertragbar. Lesetip: "Designing BSD Rootkits" (Kong), "The Linux Programming Interface" (Kerrisk) und "Advanced Programming in the UNIX Environment" (Stevens, Rago), "The Design and Implementation of the FreeBSD Operating System" (McKusick, Neville-Neil).
Dazu kommen noch die Versionsnummern auf welche ich weiter oben verwies und nicht zuletzt
Versionsskripte, welche einzelnen Funktionen innerhalb einer Bibliothek ebenfalls Versionen mitgeben.
Vielleicht gibt es aber auch standarisierte Methoden um Libc-Version und Kernelversion bei allen Distributionen rauszufinden, so ähnlich (aber hoffentlich besser strukturiert) wie bei
COM ?
Ja, die Methode heißt Dynamic Linker (ld.so) und ist
dokumentiert. Funktioniert allerdings etwas anders als in Windows.
Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.
Der GCC hat keine Probleme, der Linker gehört noch nicht einmal zu GCC, sondern zu Binutils. Zugegeben, als ich nur Delphi kannte, unterlag ich auch der Illusion daß es eines Schritts von Quelltext zur Binärform bedarf. Lesetip: das "Drachenbuch" über Compiler-Design (auf dt. "Compiler: Prinzipien, Techniken und Werkzeuge").
Wenn man die richtigen Libs und deren Position kennt kann man das zusammenbauen.
Also wäre ein C++Builder vielleicht geeigneter als Delphi um GCC Projekte zu kompilieren und einzubinden ?
Es ist herzlich irrelevant welcher
Compiler genutzt wird. Das vermeintliche Problem entsteht durch die Standardeinstellung des Linkers (und der kann gesteuert werden, so daß es überhaupt kein Problem gibt, wenn man sich damit beschäftigt).
Aber der klassische Unix-Weg wäre ja auch eher mit fork und wait statt Threads
Sehe ich auch so, aber bei uns in der Firma werden seltsamerweise oft trotzdem Threads bevorzugt. Finde es seltsam, denn bei einem Fehler ist es ja der Kernel welcher den Prozeß abschießt. Einen Mechanismus wie SEH gibt es da nicht. Kurzum: ich bevorzuge mindestens ein fork() denn nur dann kann ich den Kindprozeß überwachen und ggf. Maßnahmen ergreifen falls etwas passiert. Ist übrigens zusammen mit AFL oder den Sanitizern von Clang (und mittlerweile ja auch GCC) unschlagbar für automatisiertes Testen.
Aber ich sprach von statisch gelinkten ELFs. (keine
Exen, die gibt's unter Linux nicht
).
Wo wir schon genau sind :p
Unter Linux kann eine executable (=eine Datei die das executable-Recht gesetzt hat) jede Dateiendung haben die sie will, auch ".exe", nur hat sie üblicherweise keine Endung (oder es ist ein Skript wie .pl .sh oder eine ELF-Bibliothek .so). Das Gegenstück zu ELF in Windows sind
PE-Dateien (die auch unterschiedliche Dateierweiterungen erlauben für "normale" ausführbare Dateien aber auch DLLs/Bibliotheken/Treiber).
Ich finde exe ist da klarer als das häufige binary (was alles sein kann).
Es kann gerade nicht alles sein. Auf Linux ist für Skripte nicht das x ausschlaggebend, sondern die Hashbang (#!). Für binäre Programme hingegen gibt es eine Möglichkeit
beliebige Formate interpretieren zu lassen.
Falls du immer verwirrt bist worum es sich bei einer Datei handelt, empfehle ich das oben bereits erwähnte Tool "file", welches dir auf unixartigen Systemen üblicherweise zur Verfügung steht.
Normalerweise kompilierst du dein Programm exakt für deine Zielplattform.
Mal dumm gesprochen: Das mache ich für Windows ja auch (XP/7/8/10).
Nur das dort wohl mehr Wert auf Rückwärtskompatibilität gelegt wird (was ich mir
bei Vergleich M$ - Linux aber auch nicht wirklich vorstellen kann).
Ist das so? Mal dumm geantwortet: auf Linux überwiegen Programme mit offenen Quellen, macht da Rückwärtskompatibilität mit Präprozessor-Direktiven (ifdef etc) soviel Sinn wie auf Windows? Abgesehen davon scheint dir der Begriff
DLL-Hölle unbekannt zu sein. Möglicherweise der Segen eines jungen Lebens?
Ich habe bisher nur ein bischen mit Bash und Konsolen-GCC rumgespielt, das Hauptproblem was ich damit hatte ist "wo ist was ?".
Dann empfehle ich bspw. "apropos", "man" und "info". Wobei man die entsprechenden Handbücher vorher installieren sollte. Wer das nicht möchte, wendet sich vertrauensvoll an linux.die.net oder man7.org.
Kann natürlich sein, dass ich jetzt zufällig überall auf dieselbe Version der libc gestoßen bin, [...]
Bist du bei den genannten Versionen von Ubuntu definitiv nicht. Und selbst wenn die Versionsnummer stimmt, heißt das auf Linux oft wenig. Viele der Kernel die als 2.4er firmierten (ich sage nur Redhat) waren schon soweit gepatcht, daß sie halbe 2.6er waren. Offenliegende Quellen eben ...
Doch, ist aber so. Microsoft hat seine Plattform ja voll in eigener Hand. Linux besteht aus sehr vielen unabhängigen Projekten.
Linux besteht aus einem Kernel - Punkt. Was du vermutlich meinst ist der GNU-Aufsatz auf dem Linuxkernel
Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.
Den müßtest du - zumindest mir - nochmal erklären.
Nun ja, an Delphi hängt schon mein Herz...
Das zu hören freut die Verkaufsabteilung
Aber das käme nur ernsthaft in Betracht, wenn die Preispolitik um Delphi völlig abdreht [...]
Ich finde sie schon seit Jahren völlig abgedreht. Weiter oben erwähnte einer der Mitdiskutanten, daß es Wahnsinn sei, daß er gebündelt Pakete mit kaufen müsse, welche er nicht benötigt. Dem kann ich nur aus ganzem Herzen zustimmen. Genau deshalb habe ich mich von Delphi abgewandt.
Bis auf die "Grundeinrichtung" um das System überhaupt zum laufen zu bekommen wäre eine Linux-
GUI sowas von 1995.
Jede Weblösung die sich nicht über das Web (hier http) Administrieren lässt ist keine vollständige Weblösung
Jeder "Administrator" der eine
GUI benötigt um sich durchzufrickeln ist kein Administrator. Und da haben wir über die vielen Sicherheitslücken noch nicht gesprochen, welche allein aufgrund der webseitigen Administrationsoberflächen entstanden sind und entstehen.