Linux - Ick freu mir ;-)

[Assarbad]

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.

Zitat von Rollo62:

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.

Zitat von Valle:

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.

Zitat von Valle:

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

Code:

file <Dateiname>

auszuführen und die Ausgabe hier zu zeigen. Das hat Herr Cantu leider versäumt.

Zitat von mjustin:

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.

Zitat von Valle:

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.

Zitat von Rollo62:

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.

Zitat von Rollo62:

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.

Zitat von Rollo62:

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.

Zitat von Rollo62:

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.

Zitat von Rollo62:

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").

Zitat von Rollo62:

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).

Zitat von Namenloser:

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.

Zitat von mael:

Zitat von Valle:

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.

Zitat von Rollo62:

Zitat von Valle:

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?

Zitat von Rollo62:

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.

Zitat von Benedikt Magnus:

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 ...

Zitat von Valle:

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

Zitat von Valle:

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.

Zitat von Harry Stahl:

Nun ja, an Delphi hängt schon mein Herz...

Das zu hören freut die Verkaufsabteilung

Zitat von Harry Stahl:

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.

Zitat von Bernhard Geyer:

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.