Linux - Ick freu mir ;-)

[Rollo62]

Hallo Valentin,

dankesehr für die Ausführeungen.

Ich denke auch X11 oder Wayland sollte man ansprechen können, da ist aber harte Handarbeit angesagt.
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.
Emba hat das ja anscheinend nicht auf dem Plan.

Vielleicht noch Posix, und dann ist erstmal Schluss denke ich.
Das ist aber schonmal was.

Aber es könnte ein Blick zu FreePascal lohnen, dort ist man sicher schon etwas weiter.

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.

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.
Und dann gibt es noch zig Paketmanager, jeder kocht leider sein eigenes Süppchen.

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 ?
Hab ich aber noch nicht gesehen.

Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.
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 ?

Ubuntu ist auf Debian basierend, und ich denke eine ganze Reihe von Distributionen basieren auf Debian.
Das läst mich hoffen.

Rollo

[Namenloser]

FreePascal verwendet standardmäßig gar keine libc. Die haben fast alles notwendige selbst implementiert und sprechen direkt mit dem Linux-Kernel via Syscalls. Somit kann man an sich extrem portable Kompilate erstellen. Aufpassen muss man nur, wenn man Units einbindet, die ein vorangestelltes c haben (z.B. cmem). Diese linken gegen die libc. Leider gehört dazu auch cthreads, welche man für Multithreading braucht. Aber der klassische Unix-Weg wäre ja auch eher mit fork und wait statt Threads

[frapo]

Zitat von bernau:

Mit Delphi kann man seit Uhrzeiten Service-Anwendungen (für Windows) schreiben. Also kein neues Terrain.

Das ist mir schon klar . Mit neuem Terrain meinte ich einen Dienst dann für Linux zu schreiben. Aber wie an anderer Stelle hier schon gesagt wurde: wer Interesse daran haben wird, wird sich da auch sehr gerne reinfuchsen.

[ralfstocker]

Das wird wieder mal nix werden. Wie schon bei Kylix. Linux-Marktanteil Desktop: 1%. Und auf dem Server wird der free gcc verwendet.

[Valle]

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.

Richtig. Aber das ist normalerweise kein Problem.

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.

Nein, gibt es normalerweise eher nicht. Verschiedene Kernelversionen sowieso nicht, Libraries gibt es manchmal in verschiedenen Major-Versionen parallel. Aber genau das ist die Aufgabe deiner Distribution: Sie achtet auf die Kompatibilität deiner Libraries und Programme und kompiliert und linkt diese so, dass sie funktionieren. Das funktioniert natürlich nur, weil quasi alle Programme, die in der Distribution enthalten sind, OpenSource sind. Deshalb wird es Delphi hier sehr schwer haben.

Zitat von Rollo62:

Und dann gibt es noch zig Paketmanager, jeder kocht leider sein eigenes Süppchen.

Naja, ob man hier leider sagen kann ist fragwürdig. Primär gibt es nur DEB und RPM. Die anderen sind eher vernachlässigbar. Und Konkurrenz und Alternativen sind in der Unixwelt eine wichtige Philosophie, die dazu beigetragen haben, dass Dinge so sind wie sie jetzt sind.

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 ?
Hab ich aber noch nicht gesehen.

Normalerweise kompilierst du dein Programm exakt für deine Zielplattform. Distributionen wie Ubuntu vereinfachen das, da du dann nur ein Mal für Ubuntu linken musst und dieses Binary dann auf jedem Ubuntu dieser Version und Architektur funktioniert. Lieferst du nur ein Binary aus, linkt man häufig statisch. Dann sind alle Libraries eingebunden und das Programm ist unabhängig von seiner Umgebung. So kommst du aber nicht in die Paketlisten großer Distributionen.

Zitat von Rollo62:

Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.

Richtig! Aber: gcc gibt es für Linux. Die meisten Programme bieten also ihren Sourcecode zum Download an. Die Debian Maintainer nehmen den Source und lassen ihn automatisch für passende Zielplattformen kompilieren. Einen Delphicompiler für Linux gibt es noch nicht. Und der Aufwand für alle passenden Platformen selbst zu Linken ist vermutlich zu hoch. Daher vermute ich, dass statisches Linken die einzig sinnvolle Alternative sein wird.

[BUG]

Zitat von ralfstocker:

Und auf dem Server wird der free gcc verwendet.

Naja, den vorhandenen Business-Code und die gewohnten Tools benutzen zu können kann schon viel wert sein.

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

[himitsu]

Selbst in Windows muß eine EXE nicht EXE heißen.
Nur gibt es für andere Dateiendungen standardmäßig selten Verknüpfungen im Windows, damit es diese auch starten kann. (Windows weiß ja nicht, daß es eine PE ist, da nicht im Fileheader nachgeschaut wird).

Man kann auch eine EXE und DLL kombinieren, also alleine lauffähig und/oder als DLL ladbar. Die EXE kann sogar eigene exportierte Funktionen von sich selber dynamisch laden.

[Rollo62]

[QUOTE]

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

Wahrscheinlich gibt es unter Linux einfach mehr Versionen als unter Windows-Libraries,
aber ob es 150 oder 200 Library-Versionen gibt macht doch auch wenig Unterschied.

Die Unterschiede liegen IMHO in den verschiedenen Basisauslegungen, wie Filesystem, Mounting, Graphiksystem, Desktop, etc., das kann ich ja verstehen.
Aber ein Linux mit gleicher Auslegung (z.B. Debian-Basis) sollte sich doch sehr ähnlich verhalten.
Ich könnte dann u.U. auch fehlende Komponenten einfach nachinstallieren.

Wenn ich mir die Linuxwelt so ansehe dann liest sich alles so als gäbe es 100% Crash-Sicherheit bei komplexen Projekten.
Das kann aber so schlimm doch auch wieder nicht sein, sonst wäre es nicht so erfolgreich.

Ich habe bisher nur ein bischen mit Bash und Konsolen-GCC rumgespielt, das Hauptproblem was ich damit hatte ist "wo ist was ?".

Das es gehen muss zeigen doch Libre-Office, Firefox und zig andere.
Wie bekommen die das denn eigentlich kompatibel zu allen Distris, mit Milliarden von IFDEFs ?

Rollo

[Rollo62]

Noch ein Gedanke zum fehlenden FMX:

Das Einbinden von Chromium Embedded (mit DCef3) sollte doch überschaubar sein.
DCef3 hat zumindest FPC schon als define mit drin, obs läuft weiss ich nicht.

Dann hätte man auf einen Schlag ein state-of-the-Art visuelles GUI, mit HTML/JS Frontend und Delphi Backend.

Rollo