Linux - Ick freu mir ;-)

[Assarbad]

Zitat von Rollo62:

dankesehr für deine Erleuchtungen und Lesetips

Gern.

Zitat von Rollo62:

Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln.

Naja, also als Experten würde ich mich nicht sehen. Aber auch nicht mehr als blutiger Anfänger.

Zitat von Rollo62:

Jedenfalls denke ich das die Headerkonvertierung von den Libs zu Delphi nicht immer 1:1 und einfach sein wird, oder hat FPC schon vorgemacht das man alles butterweich eingebunden bekommt ?

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren, welche direkt auf den Systemaufrufen aufsetzt. Das macht total viel Sinn und erleichtert bspw. die Portierung auf andere unixartige Systeme ungemein, denn die glibc ist nicht gerade dafür bekannt sich an Standards zu halten. Nicht nur daß man das Lizenzproblem mit glibc umschifft, nein man kann je nach Zielsystem bspw. einfach die Nummern der Systemaufrufe anpassen und hat sofort eine lauffähige Laufzeitumgebung. Das ist exakt weswegen es SUS (ehemals POSIX) gibt. Denn die Portierbarkeit bezieht sich ja in der Tat vor allem auf die standardisierte Schnittstelle Systemaufruf, sowie die C-Laufzeit welche zu einem bestimmten Grad standardisiert ist.

Zitat von Rollo62:

Das wünschte ich mir übrigens auch unter Windows, um VC Projekte direkt im C++-Builder kompilieren zu können, aber immer wenn ich das mal versucht hatte artete das in komplette rewrites aus

Klingt auch irgendwie wie das schlechteste aus beiden Welten, es sei denn nur der BCB-Compiler würde benutzt und als Linker der von MSVC und das ganze würde in Debugsymbolen resultieren welche WinDbg lesen kann. Wobei vermutlich dazu Anpassungen seitens BCB notwendig wären. Aber Clang beweist, daß es geht.

Zitat von Rollo62:

So könnte man die ganzen bestehenden Projekte in Linux/Windows direkt ohne Umweg nutzen.

Also einige Kommandozeilenprogramme solltest du im Prinzip ohne Umweg sowohl mit BCB als auch MSVC und auf Linux mit Clang oder GCC kompilieren können. Da gibt es nur im Detail Unterschiede oder verschiedene #ifdef-Blöcke je nach System oder Compiler (siehe auch predef.sf.net).

Zitat von Rollo62:

Ich sehe aber das es Zeit wird sich mal tiefer mit Linux zu beschäftigen
(das wollte ich schon seit Jahren).

Viel Spaß und Erfolg!

@Valle: ich wollte nur noch anfügen, daß ich mittlerweile daran arbeite meine Test- und Buildumgebung als "ephemeral container" laufen zu lassen, also einen Container der aus einer Vorlage zum Erledigen einer Aufgabe und darauffolgendem Wegwerfen erstellt wird. x86_32 Linux lassen sich hervorragend auch auf einem x86_64-Host als Container betreiben (LXC oder sogar chroot über schroot).

[Valle]

Zitat von Assarbad:

@Valle: ich wollte nur noch anfügen, daß ich mittlerweile daran arbeite meine Test- und Buildumgebung als "ephemeral container" laufen zu lassen, also einen Container der aus einer Vorlage zum Erledigen einer Aufgabe und darauffolgendem Wegwerfen erstellt wird. x86_32 Linux lassen sich hervorragend auch auf einem x86_64-Host als Container betreiben (LXC oder sogar chroot über schroot).

Ja, natürlich. Hab ich das irgendwo abgestritten?

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

[Assarbad]

Zitat von Valle:

Ja, natürlich. Hab ich das irgendwo abgestritten?

Nein. Verzeih. Ich dachte nur die Information könnte interessant sein für dich. Immerhin ist das nirgends offiziell dokumentiert, daß man auch 32-bittige Gäste auf einem x86_64-Kernel laufenlassen kann (chroot oder LXC).

Zitat von Valle:

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

Kommt auf die verwendete Technik an, bei Namensräumen (LCX) kann man schon davon sprechen, daß auch ein Teil des Kernels im Container läuft, bei chroot eher nicht. Es ging aber oben auch um die Distro (also den Teil den du als Linux bezeichnetest). Da habe ich mich deiner Sprachregelung angepaßt und nun wirfst du es mir vor ...

[Valle]

Zitat von Assarbad:

Zitat von Valle:

Ja, natürlich. Hab ich das irgendwo abgestritten?

Nein. Verzeih. Ich dachte nur die Information könnte interessant sein für dich. Immerhin ist das nirgends offiziell dokumentiert, daß man auch 32-bittige Gäste auf einem x86_64-Kernel laufenlassen kann (chroot oder LXC).

Achso, danke, vielleicht brauche ich das mal.

Zitat von Assarbad:

Zitat von Valle:

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

Kommt auf die verwendete Technik an, bei Namensräumen (LCX) kann man schon davon sprechen, daß auch ein Teil des Kernels im Container läuft, bei chroot eher nicht. Es ging aber oben auch um die Distro (also den Teil den du als Linux bezeichnetest). Da habe ich mich deiner Sprachregelung angepaßt und nun wirfst du es mir vor ...

Achso, du hast dich angepasst. Entschuldigung, ich dachte nur du kämst jetzt selbst damit durcheinander. Das fand ich lustig. Nichts für ungut.

[Rollo62]

Zitat von Assarbad:

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren,...

Ja wahrscheinlich macht das Sinn einen LAyer dazwischenzuhaben.
Generell verstehe ich bei diesen POSIX-Funktionen nicht ganz WAS sih eigentlich ändert.
Ich sehe das ein bischen so wie die API zur DOS-CommandZeile, oder zu WMI, da gibt es verschiedene Katgorien:
"Mature"-Funktionen ?
- Memory Zugriff
- Filezugriff
- Sockets
- IPC
- Pipes
- Regex
- Math
- etc.
Funktionen vielleicht in "Änderung"
- SystemManagement
- ???

Von der Seite der System-Stabilität her würde ich erwarten das 98% der glibc API doch
komplett "durchentwickelt" sein müsste, zumindest hinsichtlich der APIs.
Und mögliche Änderungen beziehen sich hoffentlich nur auf Neue oder "Sonder"-Funktionen.

Oder wird auch ständig an den Grundpfeilern herumgebastelt ?

Solange die APIs gleich bleiben, und nur an der Performance verbessert wird, sollte die Anpassung
auf neue Versionen doch relativ simpel bleiben.
Ich kann mir einfach nicht vorstellen das man bei jeder Version alles wieder auf den Kopf stellt.

Rollo

[Assarbad]

Zitat von Rollo62:

Generell verstehe ich bei diesen POSIX-Funktionen nicht ganz WAS sih eigentlich ändert.

Bin mir nicht sicher was genau du damit meinst. Wenn du meinst von System zu System (bspw. GNU/Linux vs. FreeBSD) oder über die Zeit, dann wäre beispielsweise die Änderung von time_t von einem 32-bittigen Typen zu 64-bit eine ABI-inkompatible Änderung, die aber bei einfacher Neukompilierung keine Rolle spielt. Denn SUS/POSIX sorgt für Kompatibilität auf Quelltextebene (Stichwort: Portierbarkeit).

Zitat von Rollo62:

Ich sehe das ein bischen so wie die API zur DOS-CommandZeile, oder zu WMI, da gibt es verschiedene Katgorien:
"Mature"-Funktionen ?
- Memory Zugriff
- Filezugriff
- Sockets
- IPC
- Pipes
- Regex
- Math
- etc.
Funktionen vielleicht in "Änderung"
- SystemManagement
- ???

In der Tat. Wenn du willst, kann ich dir das Inhaltsverzeichnis von The Linux Programming Interface schicken. Melde dich ggf. per PN.

Zitat von Rollo62:

Von der Seite der System-Stabilität her würde ich erwarten das 98% der glibc API doch komplett "durchentwickelt" sein müsste, zumindest hinsichtlich der APIs.
Und mögliche Änderungen beziehen sich hoffentlich nur auf Neue oder "Sonder"-Funktionen.

Oder wird auch ständig an den Grundpfeilern herumgebastelt ?

Eine Prozentzahl kann ich dir nicht geben, aber manchmal wird in der Tat auch an Grundpfeilern herumgebastelt um bspw. die Sicherheit zu erhöhen (bspw. Schutz gegen Pufferüberläufe und dergleichen). Aber in der Tat ändert das an den Schnittstellen wenig. Nur leider ist es so, daß einige Anwendungen sich auf glibc festlegen statt einfach eine C-Laufzeitbibliothek zu erwarten. Das tun sie wahlweise indem sie glibc-spezifische Schnittstellen verwenden oder indem sie Interna benutzen. Nicht zuletzt führt auch die falsche Benutzung von Defines (auch in glibc selbst) zu Inkompatibilitäten auf Quelltextebene (hier wird also eine Neukompilierung angestrebt).

Zitat von Rollo62:

Solange die APIs gleich bleiben, und nur an der Performance verbessert wird, sollte die Anpassung
auf neue Versionen doch relativ simpel bleiben.
Ich kann mir einfach nicht vorstellen das man bei jeder Version alles wieder auf den Kopf stellt.

Da hast du recht. Aber ich verstehe nicht ganz worauf du hinaus willst?!

Ein altes Programm welches, sagen wir mal, vor 10 Jahren gegen glibc gelinkt wurde auf einer damals aktuellen Distro, läuft ja üblicherweise problemlos auf einer neueren Distro. Umgekehrt aber nicht. Also ein auf einer neueren Distro gelinktes Programm mit älterer glibc.

Hier zwei Beispiele von Funktionen bei denen man die Kompatibilität mit älteren glibc-Versionen erzwingen muß: memcpy und realpath. Das erreicht man folgendermaßen. Man erzeuge ein Macro entsprechend der glibc-Version zu der man Kompatibilität herstellen möchte:

Code:

#ifdef __amd64__
#   define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.2.5");
#else
#   define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.0");
#endif /* __amd64__ */

Hinweis: 2.2.5 war die erste Version mit Unterstützung für amd64 bzw. x86_64. Der Parameter fct ist dabei der Name der Funktion, welcher mithilfe des Stringification-Operators (#) zu einem Literalstring wird. Zu .symver siehe hier.

Angewendet wird das Makro dann wie folgt:

Code:

GLIBC_COMPAT_SYMBOL(realpath)
GLIBC_COMPAT_SYMBOL(memcpy)

Mit dem Effekt, daß nunmehr nicht die neueste Version von memcpy und realpath, sondern die älteste Version benutzt wird. Die Methode kann man übrigens der Datei include/libc-symbols.h entnehmen welche sich in (e)glibc befindet.

Für jene die nachvollziehen wollen welche Symbole in welcher Version vorliegen, hier eine Möglichkeit:

Code:

$ readelf -a /lib/x86_64-linux-gnu/libc.so.6|grep ' memcpy@'
  1123: 0000000000091620    61 IFUNC   GLOBAL DEFAULT   12 memcpy@@GLIBC_2.14
  1125: 000000000008c420    71 IFUNC   GLOBAL DEFAULT   12 memcpy@GLIBC_2.2.5

[creed steiger]

Zitat von Rollo62:

Zitat von Assarbad:

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren,...

Ja wahrscheinlich macht das Sinn einen LAyer dazwischenzuhaben.

eigentlich genau das Gegenteil, in diesem Fall unnötige Abhängigkeiten zu reduzieren

http://wiki.freepascal.org/libc_unit

[Rollo62]

Ja dankesehr für das Beispiel, das macht es schon etwas klarer.
Also kommt man ggf. doch in die IFDEF-Hölle, wenn man nicht aufpasst.

Ich versuche meistens immer eher einen Grundsatz von Funktionen zu verwenden, und Spezialitäten erstmal wegzulassen.
Also z.B. strcpy, memcpy, etc. solche Funktionen die es schon seit den 60ern unverändert geben sollte.

Sollte doch möglich so einen Satz Grundfunktionen zu finden wo die API nicht komplett verrückt spielt,
und ich gehe für mich jetzt mal vom aktuellsten Linux aus.
Muss ja bei Neuprojekten nicht 20 Jahre rückwärtskompatibel sein.

Ich warte mal ab wie das im neuen Delphi umgesetzt wird, da bin ich schonmal gespannt.

Rollo