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