# Frage zu linux-headers

## sprittwicht

Ja, ich weiß: Das Thema war hier schon _einige_ Male...  :Smile: 

Hab auch dutzende von alten Threads gelesen, bin aber noch'n bisschen unschlüssig.

Also los: emerge will bei mir unbedingt linux-headers-2.4.21 installieren (derzeit installiert: 2.4.19-r1). Ich benutze momentan folgende Kernel: gentoo-dev-sources-2.6.1 und gentoo-sources-2.4.22-r4. Außerdem sind glibc-2.3.2-r9 und gcc-3.3.2-r5 installiert.

Wenn ich's so weit richtig verstanden hab, sollte ich von den 2.6er linux-headers erstmal die Finger lassen, weil einige Ebuilds dran scheitern werden und der einzige Vorteil ohnehin nur die Unterstützung von nptl wäre. Meine Vorgehensweise wäre dann jetzt:

1. emerge -C linux-headers-2.4.19-r1 (weil Portage sonst angeblich meint, BEIDE linux-headers-Pakete wären installert)

2. emerge linux-headers-2.4.21

3. emerge glibc (nach headers-Update unbedingt notwendig)

4. emerge gcc (da bin ich mir nicht sicher, ist der notwendig?)

5. Jetzt kommt eigentlich die Stelle, zu der ich mir aufgrund diverser älterer Threads keine eindeutige Meinung bilden konnte. Die Meinungen/Erfahrungen gingen von "alles läuft ohne Probleme" über "einige Programme laufen nicht mehr und müssen neu kompiliert werden" bis hin zu "ALLES muss neu kompiliert werden".

Irgendwo hab ich dann gelesen, dass "normale" Programme eigentlich nur neu kompiliert werden müssen, wenn man eine komplett neue Version der glibc installiert, weil sich halt die Größen einiger structs geändert haben könnten oder sowas. Bei kleineren Versionssprüngen sollte das aber kein Problem sein.

Meine Frage: Wenn ich "nur" die linux-headers update, kann das zu derart schwerwiegenden Änderungen an der neu kompilierten glibc führen?

Wie kann ich nach dem Neukompilieren der glibc wissen, ob derart problematische Veränderungen stattgefunden haben? Nur per Trial&Error (Och, dieses und jenes Programm geht plötzlich nicht mehr, kompilier ich's halt neu.)?

Letzterer Weg scheint mir doch sehr gefährlich zu sinn, da man viele Fehler vermutlich nicht so deutlich bemerkt. Vermutlich kann ein glibc-Update da doch enorme Sicherheitslöcher ins System reißen, oder nicht?

Der einzige 100% sichere Weg scheint mir, nach jedem Update der glibc (und somit auch nach jedem linux-headers-Update) das komplette System neu zu kompilieren. Das kann doch nicht sein?? Sagt mir bitte, dass ich dramatisiere, phantasiere oder was auch immer, ich will nicht alles neu kompilieren!

Um von der eher allgemeinen Diskussion nochmal auf meine konkrete Situation zurückzukommen:

Wenn ich die obigen Schritte 1-4 bei meiner aktuellen headers/Kernel/glibc-Kombination durchführe, hab ich größere Probleme zu erwarten?

----------

## steveb

also so wie ich das neue glibc ebuild erlebt habe, sucht es selbst nach den modulen, die eine neue übersetzung brauchen und nimmt rücksicht darauf.

also kannst du ohne weiteres einfach die neuen header emergen und dann müsstest du lediglich glibc neu übersetzen und das wäre es schon.

gruss

SteveB

----------

## amne

Im Grossen und Ganzen weiss emerge am Besten, was sinnvoll ist. Insofern finde ich es im Allgemeinen am Sinnvollsten, es das tun zu lassen, was es vorschlägt. Sofern dann doch noch etwas neu zu kompilieren ist, sollte bei der Installation eh eine Meldung kommen, was zu tun ist (Ätsch, zu spät  :Wink: ) - oder es kümmert sich von selbst darum.

Manuelles Deinstallieren mittels -C ist meist keine gute Idee, manchmal bleibt eine alte Version ebenfalls installiert, damit nichts kaputtgeht (Stichwort SLOTS), falls die alte Version obsolet ist, wird sie eh von selbst deinstalliert. Es ist schon ein paar mal vorgekommen, dass jemand vor dem Upgrade python, portage oder die coreutils deinstalliert hat und dann gar nichts mehr machen konnte.  :Wink: 

----------

## sprittwicht

Hm, bin jetzt irgendwie genauso schlau wie vorher, was die Problematik headers/glibc-Updates angeht. :-/

Das mit dem "emerge wird schon wissen, was zu tun ist" ist mir'n bisschen zu unsicher. Z.B. hat er glaub ich nicht verlangt, nach der Installation der neuen Header die glibc neu zu kompilieren, was aber doch wohl absolute Pflicht ist...

Ansonsten hab ich jetzt brav die neuen Header und glibc nochmal installiert. Die alten Header hab ich von Hand geunmerged (geiles Wort!), weil irgendwo stand dass die im Zweifelsfall eh überschrieben werden, und man somit nur noch die Portage-Einträge als Leichen im System hat, während die dazugehörigen Dateien von den neuen Headern überschrieben wurden.

Normalerweise sollten ale Header doch auch von emerge entfernt werden, oder ist es möglich/in bestimmten Situationen sinnvoll, mehrere Versionen von linux-headers installiert zu haben? Können ältere Versionen Header beinhalten, die vom System benötigt werden, in der neuen Version aber nicht mehr drin sind? Dieses ganze Header-Wirrwarr ist mir sehr suspekt.

Andere Frage: Muss man denn nun nach einem glibc-Update auch den gcc neu installieren? Hab's jetzt zwar gemacht... Tut ja auch nicht weh, wenn man die Zeit hat... Aber wenn nicht: Meine Fresse, das dauert vielleicht...  :Smile: 

----------

## deepthought

Auch wenn diese Frage schon mindestens zehnmilliardenmal beantwortet worden ist:

1. Die alten Header werden überschrieben. Warum die Maintainer des "linux-headers"-Paketes trotzdem mit SLOT und noclean installieren, ist mir bisher verborgen geblieben.

2. Es macht gar keinen Sinn, mehrere Kernelheaderversionen zu haben. Die glibc kompiliert gegen diejenige, die unter /usr/include/linux liegt, punktum.

3. Was nptl betrifft, so handelt es sich um die berühmte Ausnahme zur Regel. Hier wird nicht geprüft, ob die Header des Betriebssystems (in Deinem Fall 2.4.*-schlagmichtot) passen, sondern ob der aktuell laufende Kernel nptl unterstützt. Das ist aber deshalb kein Problem, weil niemand außer der glibc das Threading des Kernels direkt benutzt.

4. Es genügt, die glibc mit USE="nptl" neuzukompilieren: die Schnittstelle, über die der Rest (ja, wirklich alles...) auf Threadingfunktionalität zugreift, ist gleich geblieben; das einzige, was sich geändert hat, ist die Implementierung der Schnittstelle (nptl statt linuxthreads).

Ich hoffe, jetzt ist es ein für allemal klar.

Viele Grüße,

Alexander

----------

## sprittwicht

Damit wären die wesentlichen Fragen geklärt, danke.  :Smile: 

 *Quote:*   

> Auch wenn diese Frage schon mindestens zehnmilliardenmal beantwortet worden ist

 

Das ist ja eben das Problem! Je länger man sucht, umso widersprüchlichere Antworten findet man. Irgendwann dampft einem nur noch die Birne...

Eine Frage hätt ich aber noch gern geklärt.  :Smile: 

Welche Programme muss / sollte man nach einem Update der glibc neu kompilieren? Tut mir ja wirklich leid, wenn die Frage dumm ist / tausendmal gestellt wurde / einfach nur nervt, aber ich finde dazu beim besten Willen keine klaren Aussagen. In der bootstrap.sh steht lediglich, dass gcc und binutils nach der glibc nicht nochmal kompiliert werden, wie es wohl früher mal der Fall gewesen sei. Allerdings wird gettext im Bootstrap-Prozess zweimal kompiliert.

Aber was heißt das für mich (nach einem späteren glibc-Update)? Wenn ich gcc nicht neu kompiliere, muss ich mit Instabilitäten rechnen? Gehen mir evtl. einige neue Features flöten? Muss ich vielleicht gettext neu kompilieren, oder war das nur ne einmalige Sache nach dem Bootstrap-Vorgang?

Sorry, ich will hier echt niemandem auf den Geist gehen, aber ich hab echt keinen Dunst wo ich noch suchen soll.. :-/

----------

## deepthought

Fragen über Fragen... Also:

1. Solange es sich um ein "minor update" handelt, brauchst Du eigentlich gar nichts neuzukompilieren; die neue Version ist im Normalfall ABI-kompatibel (heißt: die Schnittstellen, über die andere Programme auf die glibc zugreifen, sind auch im Binärcode gleich geblieben) zur alten. Sobald größere Änderungen anstehen, mußt Du alles, was die glibc verwendet (also alles) neukompilieren.

2. Kleine Änderung heißt: 2.x.y -> 2.x.z (z.B. 2.3.2 -> 2.3.3); große Änderung heißt: 2.x.z -> 2.y.z (z.B. 2.3.<irgendwas> auf 2.4.<irgendwas>).

3. Wenn Du es ganz sauber haben willst, mußt du es so machen wie die LFS-Jungs: Alles, was zum Bauen der glibc erforderlich ist, statisch kompilieren; glibc kompilieren, alles neukompilieren und alte Versionen löschen. Das ist aber eigentlich nicht erforderlich.

4. Probleme treten normalerweise nur beim "major update" auf.

Probleme mit neuen "Features" sollte es eigentlich nicht geben: es ist ja nicht damit getan, daß die glibc neue Features enthält; sie müssen ja auch von der jeweiligen Anwendung genutzt werden -- dann würde man das aber über die Paketabhängigkeiten angeben. Abgesehen davon sind die glibc-Entwickler sehr (SEHR) konservativ bei Anpassungen und Änderungen: da so viele Programme von dieser Bibliothek abhängen, ist die oberste Direktive "kompatibel bleiben".

Mach' Dir einfach nicht zuviele Sorgen; die anderen haben nicht ganz Unrecht mit der Aussage "emerge weiß, was es tut" -- denn genau hier liegt ja die Aufgabe der Paketmaintainer.

Viele Grüße,

Alexander

----------

## sprittwicht

DANKE!  :Smile: 

Jetzt ist mein Gewissen erstmal wieder beruhigt...

----------

