Linux - Ick freu mir ;-)

[Valle]

Zitat:

Zitat von Assarbad (Beitrag 1346896)

Zitat:

Zitat von Valle (Beitrag 1346895)

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

Zitat:

Zitat von Assarbad (Beitrag 1346896)

Zitat:

Zitat von Valle (Beitrag 1346895)

(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 ... :roll:

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

[Rollo62]

Zitat:

Zitat von Assarbad (Beitrag 1346893)

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:

Zitat von Rollo62 (Beitrag 1346939)

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:

Zitat von Rollo62 (Beitrag 1346939)

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:

Zitat von Rollo62 (Beitrag 1346939)

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:

Zitat von Rollo62 (Beitrag 1346939)

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:

Zitat von Rollo62 (Beitrag 1346939)

Zitat:

Zitat von Assarbad (Beitrag 1346893)

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

[Benedikt Magnus]

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

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

Unter FreePascal habe ich ein paar recht große Projekte laufen, die sowohl für Windows als auch Linux kompiliert werden. In allen zusammen genommen findet sich genau zwei IFDEFs, und zwar zur Festlegung des Pfadtrenners (Slash/Backslash) und zur Ermittlung der Systemsprache. Es ist also halb so wild.

[jaenicke]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346999)

In allen zusammen genommen findet sich genau zwei IFDEFs, und zwar zur Festlegung des Pfadtrenners (Slash/Backslash)

Da Windows auch den Slash unterstützt, ist das noch nicht einmal unbedingt immer nötig, je nachdem was man damit macht.

[Assarbad]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346999)

Unter FreePascal habe ich ein paar recht große Projekte laufen, die sowohl für Windows als auch Linux kompiliert werden. In allen zusammen genommen findet sich genau zwei IFDEFs, und zwar zur Festlegung des Pfadtrenners (Slash/Backslash) und zur Ermittlung der Systemsprache. Es ist also halb so wild.

Das geht und weist auf eine von zwei Möglichkeiten (oder beide) hin: 1.) die grundlegenden Bibliotheken von FreePascal sind saugut konzipiert und/oder 2.) dein Projekt benutzt überhaupt nur wenige systemspezifische Konstrukte.

Vergessen darf man auch nicht, daß du den gleichen Compiler benutzt, möglicherweise sogar denselben, falls du cross-kompilierst. Wenn du jeweils GCC auf Windows, Linux, AIX und Solaris benutzt können dir viele Probleme anderer Leute mit ifdefs auch wumpe sein. Sobald aber schon ein Strauß verschiedener GCC-Versionen benutzt wird, kommste u.U. in unruhige Gewässer. Wenn dann dein Code auch noch gewisse Anforderungen an den Compiler hat (Speicherausrichtung auf 64-bit SPARC [1], bspw.) und der GCC in seiner vorhandenen Version genau dort schwächelt, kommste um eine Alternative für GCC schon nicht mehr herum (SunC/Sun Studio). Wenn du aber bspw. auf Windows auch sinnvoll post-mortem Debugging mit Minidumps machen willst, brauchste DbgHelp-kompatible Symbole, welche der GCC (bzw. der benutzte Linker) nicht erstellt. Also stellste in Windows auf MSVC um. Und so weiter und so fort. Dann sind wir bei vier Systemen schon bei drei Compilern (jeweils gleiche Sprache C/C++), wobei die Versionsunterschiede noch nicht mitgerechnet sind. Da lassen sich #if und #ifdef selten vermeiden. Bei der Software für die ich beruflich verantwortlich zeichne, habe ich es, je nach Paket, mit bis zu 14 Plattform/Prozessorarchitektur-Paaren zu tun. Und da sind dann die OS-Versionen noch nicht mitgerechnet, sei es wegen glibc oder wegen einer inkompatiblen ABI-Änderung.

Aber ich hoffe daß hier die Konkurrenz (FPC vs. Delphi) die treibende Kraft ist und sich die Entwickler von Delphi ein Beispiel an der tollen Umsetzung bei FPC nehmen. Bei Clang vs. GCC hat es ja geklappt. Die hilfreichen Fehlermeldungen gibt es nun schon eine Weile auch mit dem GCC und die Sanitizer wurden auf GCC portiert.

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

Also kommt man ggf. doch in die IFDEF-Hölle, wenn man nicht aufpasst.

Der Nachsatz ist wichtig: wenn man nicht aufpaßt, ja. Und selbst wenn man aufpaßt, sollte das Aufpassen so sorgfältig geschehen, daß man sich keine eigenen Probleme schafft (bspw. statt mit den IFDEFs Unterschiede zu betonen, lieber Gemeinsamkeiten der jeweiligen Varianten betonen).

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

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.

Der Witz ist, daß es mit SUS/POSIX vermutlich in vielen Fällen dennoch (quelltext-)rückwärtskompatibel ist. Es sei denn du machst eklige Sachen wie eigene Typen in Fällen einzusetzen wo eingebaute und Bibliothekstypen benutzt werden sollten (bspw. direkt irgendwelche Integer statt ptrdiff_t, off_t).

Und viele der API-Funktionen die spezifisch nur für ein System entwickelt wurden (vfork, wait3, wait4), haben es auch schon in andere Systeme geschafft (bei Linux/FreeBSD mehrfach), bei anderen gibt es gute Alternativen. Aber in vielen Fällen wird das erst dann relevant wenn du deinen Code auf Geschwindigkeit trimmst oder ähnliches. Solange du ein 08/15-Programm schreibst (also keinen Datenbank- oder Webserver) und mit der Geschwindigkeit zufrieden bist, tun es auch jene Funktionen für Speicherverwaltung, Stringverarbeitung und E/A, welche auf allen unixartigen Systemen quelltextkompatibel implementiert sind.

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

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

Ich auch. Hoffe auf Rückmeldungen in diesem Thema. Da werd' ich dann ja benachrichtigt.

[1] Speicherausrichtung wird relevant wenn du bspw. auf Integer zugreifst die nicht korrekt ausgerichtet sind. Zwar geht auch das bspw. in SunC und GCC, aber es führt zu einer Geschwindigkeitsreduktion, weil die Ausrichtung auf Prozessorebene erwartet wird. Sind Daten falsch ausgerichtet, kommt es zu einem Fehler ähnlich wie bei einer Division durch Null. Dieser Fehler kann abgefangen und behandelt werden, aber diese Behandlung führt eben zu Performanceverlusten.