CFLAGS und gcc - Lohnt sich ein Update?

[ChrisJumper]

Hi, ich wollte nur mal fragen ob ihr eure CFLAGS anpasst?

Ich habe ein System mit march=core2 gebaut, obwohl es eigentlich eine ivybridge CPU besitzt:

Laut gcc-4.9.4 Handbuch unterstützt die Version mittlerweile auch ivybridge. Hier die Unterschiede:

[ChrisJumper]

Also ich baue gerade mein System neu und muss sagen, das ich bisher von der Performance überrascht bin, die Pakete rauschen nur so an mir vorbei. Sicherlich war das vorher auch schon schnell, aber aktuell ist es zumindest etwas besser.

Es lohnt sich auf jeden Fall nach Jahren noch mal in die Compiler-Flags zu schauen und das System komplett neu zu bauen beziehungsweise auf den aktuellen stand zu bringen. Aber ich denke auch werde ich deswegen auf dem neuen System direkt gcc 6.3 ausprobieren.

Aber mal schauen in welche Probleme ich laufen und ob es nachher vielleicht doch nicht stabil läuft.

Notiz Nummer 1:
sys-apps/net-tools-1.60_p20160215155418 hatte eine redefinition drin, weshalb der 4.9.4 Compiler abbrach und ich erst mal Version 1.60_p20161110235919 in die keywords hinzufügen musste.

Notiz Nummer 2:
media-tv/mythtv hat bei den Abhängigkeiten für das hls? Useflag die Zeile

[rogge]

Ohhh ja, es lohnt sich. Und wie! Obwohl ich gleich zur Einschränkung hinterherschicken muss, dass ich "lediglich" von core2 auf nehalem gesprungen bin.
Ich kann mich leider nicht entsinnen, ob es den Nehalem vor drei Jahren, als ich mir meinen Quad-Core gebraucht gekauft habe, auch schon gab und ich core2
nur aus Verlegen- oder Sicherheit gewählt habe. Denn core2 soll offiziell nur 'MMX, SSE, SSE2, SSE3 and SSSE3' unterstützen, ich hatte aber auf jedenfall von
Anfang an auch 'SSE4.1, SSE4.2' drin stehen. Keine Ahnung ob das dann überhaupt anschlug. Dank der "Tricks" von https://wiki.gentoo.org/wiki/CFLAGS war
es nun erstmals möglich wirklich alles rauszufinden, was da noch geht. Ich bin jedenfalls sehr dankbar, dass ich über diesen Thread gesolpert bin

[ChrisJumper]

Hi rogge,

also mein ivybride System läuft auch genau so wie es soll. Aber von meinem Test mit dem 6.3.0 gcc bin ich erst mal zurück getreten. Nach der Installation wollte der Kernel einfach nicht booten, auch ein neuer anderer Kernel mit minimal frisch eingestellter .config wollte das nicht.

Nach einem Versuch gcc auf 6.3.0 zu heben um das System mit "Skylake" zu compileren, davon rate ich aktuell noch ab. Obwohl emerge -e komplett durch lief. Stellte ich später auf gcc-4.9.4 zurück und selbst das hat nicht so gut geklappt (libcrypt hatte einen Nullpointer fehler). Zwar lief der Rest später nach einem emerge -e System durch, aber ich kam nicht an dem Problem vorbei das der Kernel nach der grub2 Bootsequenz, entpackt wurde, trotzdem nicht botten wollte.

Darauf hin wird das System jetzt noch mal neu aufgesetzt. Wohl bemerkt hatte ich es halt aus dem chroot der Kali-Linux Live Umgebung umgestellt. Vielleicht war das auch kein guter Zug. Wäre das neu bauen nicht so anstrengend, hätte ich auf jeden Fall noch mehr Zeit aufgewendet um den Fehler zu finden.

Also ich wollte nur vor dem Übereifrigen ausprobieren von 6.3.0 abraten, zumindest bei der Installation. Hier im Forum haben andere den 6.3.0 Kernel aber schon mit wenigen Problemen im Testing. Aber da sollte man vorher schon quer-Lesen. Für einen mögilchen Produktiv-Einsatz ist aber auf jeden Fall noch abzuraten, das kostet nur Zeit.

Grüße

Chris

Edit: Seltsam. Mein - der Rechner bootet, entpackt den Kernel aber danach passiert nichts mehr-Problem hatte wohl nichts zu tun mit dem gcc-6.3.0. Das neu aufgesetzte System hat jetzt genau das selbe Problem.

[l3u]

Die vom GCC benutzen CFLAGS, die durch march=native gesetzt werden, bekommt man übrigens so:

[ChrisJumper]

Danke für den Hinweis l3u!

Ich habe mittlerweile alles am laufen. Die Mischung aus GPT, Systemd, einem USB-Keyboard das nach dem Booten nicht ging, in Kombination mit einem default Error-Log nach getty1 und bestimmt fünf mal Booten weil ich alle möglichen framebuffer Treiber ausprobiert hatte, die aber alle nur dazu führten das mein Kernel nach dem entpacken (decompress) eben nicht gebootet werden konnte.

Musste ich fest stellen das es Anfangs wahrscheinlich nicht der unstable gcc-6.3.0 Kernel lag.

Zudem hatte ich auch noch futex im Kernel deaktiviert, weil ich dachte das Systemd-Kernel Howto, zeigt nur das an was gesetzt werden muss, aber für den Fall das es deaktiviert werden musste, steht da ja der Eintrag mit zwei leeren Klammern davor. Jedenfalls hatte ich alle "expert User" Einstellungen raus genommen weil ich dachte das sind alles Instabile Einstellungen.

Heraus kam dann aber das eben das Deaktivieren für Experten gedacht ist, quasi printk und eben Futex ausschalten und somit einen kleinen Kernel erzeugen der weniger Speicher braucht. Aber bei den Punkten steht das alles in der HELP, ich hätte sie nur vorher lesen sollen.

Ah und einen Klassiker Fehler hab ich gemacht, bei der fstab root unter /root statt / eingehängt.

Alles in allem kein Hexenwerk, aber sehr ärgerlich ist die framebuffer Sache, weil Intel diese Grafik-Chips ja in die CPUs einbaut und im Kernel dann Treiber voreingestellt sind, die aber wenn man einen modernen Grafikchip hat, eben dazu führen das es nur ein schwarzes Bild gibt oder eben der Boot-Prozess hängt.

Da sollte unbedingt ein Test-Script her oder ein Wartungs-Modus, wenn man eine Maschine zum ersten mal aufsetzt.

[rogge]

Ich hab den hier gleich noch eingespielt: https://github.com/graysky2/kernel_gcc_patch/
Läuft!

Mit dem emerge -e hatte ich auch keine nennenswerte Porbleme.

[musv]

Danke für den Patch. Weiß nicht, ob der wirklich spürbar was bringt, aber ich hab ihn mal in meine Kernelconfig reingenommen.

[Child_of_Sun_24]

Die Cflags/Cxxflags sind die Compiler Optionen die bestimmen welche Funktionen er nutzt um den Code zu Übersetzen.

Die CPU_FLAGS_X86 sind für die Programme die dadurch angewiesen werden (Sofern sie diese Flag unterstützen) die angegeben Optionen für den Programmbetrieb zu nutzen.