SuSE 9.3 neukompilieren

ne-t-ux

Newbie
Aloha Linux-Gemeinde.

Ich habe gerade einen 350MHz Pentium2 Ibm 600er Thinkpad vor mir und mir die minimale Installation auf die 5Gb Festplatte installiert. Daraufhin besorgte ich mir von Suse alle Quellen und diejenigen die diese Quellen brauchen, von Yast2 jedoch nicht so ausgegeben wurden und installierte sie zusaetzlich bevor ich dies alles neukompilierte. Einige src.rpms funzten garnicht. filesystem*.src.rpm bricht mir immer vorm Schreiben der neuen Pakete ab da es einige Verzeichnisse nicht gibt. Wie zB sshd welches ich nicht installiert habe was ich auch nicht brauche. Dies wird naemlich ein Laptop fuer meine gute Mutter die nie im Internet noch im Netzwerk sein wird. Und da es unter yast und beim neukompilieren als abhaengigkeit nicht angezeigt wird, bin ich sprachlos.

Das war das erste problem.
das zweite ist, das ich nun die Quellen die nicht zu kompilieren gingen in der bekannten form draufliess und nach einer Kernelkompilierung alle Pakete nochmals neukompilieren liess. Warum? aus Erfahrungswerten und weil ich mir vormachte erst den gcc und alles weitere fuer eine eigene kompilierung selbst kompilieren zu lassen und dann den Kernel um mit dem neuen Kernel bei einer nochmaligen Kompilierung noch mehr platz zu sparen. nunja vielleicht war es auch sinnlos. um jedoch beim problem zu bleiben. nun werden Quellen nicht kompiliert die er mir aber beim ersten Mal kompiliert hatte.
wie evms, wo abgebrochen wird weil unpackaged file(s) in /sbin naemlich evms_mathd gefunden wurden.

das dritte prob ist xorg-x11*src.rpm hier wird abgebrochen wenn er in /usr/src/linux/scripts/ nach Makefile.mod schaut sie findet aber auch wie in dieser datei sinnvoll eingetragen include .config finden moechte, es aber nicht tut.

was sind meine Probleme und hilft eine neukompilierung fuer ein schneleres System ueberhaupt?
 
ne-t-ux schrieb:
[...] hilft eine neukompilierung fuer ein schneleres System ueberhaupt?
Nein, natürlich nicht. Wie kommst Du denn überhaupt auf diesen Unsinn?

Lass Dir mal keinen Quatsch erzählen: Software interessiert sich nicht dafür, von wem und auf welchem Rechner sie kompiliert wurde, sondern nur dafür, wie sie kompiliert wurde, d.h. mit welchem Compiler, mit welchen Flags usw.

Wenn Du die Source-RPMs von SuSE nimmst und neu baust, dann sind die daraus resultierenden Binaries exakt dieselben wie die, die ursprünglich mitgeliefert wurden.

Und allen anderslautenden Falschbehauptungen sind die fertigen Pakete sehr gut gemacht und ausreichend optimiert, um genau zu sein mit den Flags "-O2 -march=i586 -mtune=i686". Bilde Dir nicht ein, Du könntest es besser...

Falls Du trotzdem meinst, ein selbstkompiliertes System laufe schneller, dann nimm um Gottes Willen keine Binärdistribution, sondern Gentoo oder LFS. Die sind wenigstens darauf ausgelegt, komplett selbst kompiliert zu werden und bringen entsprechende Tools mit.
 

ne-t-ux

Newbie
Guten Morgen traffic,

Danke fuer Deine Antwort, hatte schon geglaubt dies wuerde nur gelesen werden. Hat mein schoener Laptop als i386er System keine Systemkomponenten die juengere System jedoch mitbringen und deshalb ein neukompiliertes Paket nur wirklich Optionen Funktionen und Verknuepfungen die es wirklich brauch und faellt deshalb kleiner aus? Habe mir bis eben echt vorgemacht, dass dies so laeuft und dadurch beim Betrieb nur wesentliches in den Speicher geladen wird und dies dann, weil reduziert, schneller, und da es im gesamten System, dem gesamten Paketvolumen so sein wuerde, er doch um einiges schneller wird. nun denn. Verkalkuliert gibt es im Duden auch ;).
Des weiteren dachte ich auch das zB. rpmbuild mit configure arbeitet und dadurch die Flags automatisch meinen Systemanforderungen und den anderen installierten Paketen angepasst wird. zB das postfix erkennt das ich mysql DBI nicht habe weil nicht brauche und er diese Verknuepfung damit nicht setzt. Gibt es vielleicht sogar die Moeglichkeit mit make menuconfig im extrahiertem Quellverzeichnis */SOURCES/*<versionsnummer> zu arbeiten um gegebenenfalls zB Treiberpakete so anzupassen das sie nur diejenigen unterstuezen die ich in kenntnis habe und alle anderen weil neues geraet dann nachtraeglich hineinkompiliert werden koennen. Wie Rechner in etwaigen Buerows wo man weiss was man hat und welche Unterstuetzungen der Rechner alles mitbringen soll?

viele Gruesse und maxinmale Erfolge hochachtungsvoll ne-t-ux
 
Moin ne-t-ux,

wie traffic dir schon schrieb: Nimm Gentoo oder LfS für diesen Zweck und Du kannst dein System wirklich optimal anpassen, aber dafür bedarf es einiges an Hintergrundwissen.

Wenn ich jetzt aber deine Kettensätze richtig interpretiere, willst Du nur einen Kernel selber bauen und eine Minimalinstallation vornehmen und diese nur um wirklich benötigte Pakete erweitern? Das kannst Du auch mit SuSE machen ohne die Pakete selber neu zu kompilieren.
 

ne-t-ux

Newbie
Den Kernel hab ich auch schon geschafft. Im Endeffekt wollte und hab ich von Suse minimal installiert und die Pakete die selbst auf prof nicht drauf sind mir ueber den FTP-Server gesaugt. Hab dann diese Quellen neukompiliert und daraufhin den Kernel. Da ich dachte das so aus den Quellen noch einiges ausscheidet. Da zB das netzwerk nicht unterstutzt wird von "meinem" Kernel, wenn ich diese Quellen nun nochmals kompiliere. Falsch Gedacht? Fast AnfaengerPech.
 
Die ganze SuSE-Distribution inklusive aller darin enthaltenen Pakete ist mit

-O2 -g -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2

übersetzt. Besser geht es nicht!

"-march=i586 -mtune=i686" bedeutet: Hochoptimiert für Pentium Pro, aber so, dass es auch noch auf einem normalen Pentium läuft.

"-O2" bedeutet: Der höchste Optimierungslevel, der Sinn macht. "-O3" klingt verlockend, ist es aber nicht, weil der Code dann im Schnitt 25% größer wird, was wiederum massig Performance kostet. Das ist nur in Ausnahmefällen sinnvoll (zlib, libpng), auf diese Ausnahmefälle hat SuSE bereits beachtet.

"-g" bedeutet: Debug-Information. Das klingt schlecht, ist aber in Wirklichkeit besser als ohne, weil Debug-Information den Linker in die Lage versetzt, Code-Größe zu sparen. Die Debug-Information wird dann am Ende rausgestrippt, fertig ist der auf Größe optimierte Code.

"-fmessage-length=0" bedeutet gar nichts. Das bewirkt nur, dass der Compiler beim Übersetzen keine dämlichen Zeilenumbrüche einfügt, die die Build-Logs unlesbar machen. Die erzeugten Binaries beeinflusst das nicht.

"-D_FORTIFY_SOURCE=2" ändert einige in den System-Headern definierte Funktionen so ab, dass auf Sicherheit überprüfte Ersatzfunktionen verwendet werden.

Damit hat man ein System, das auf jedem Rechner gut läuft. Wenn Du jetzt immer noch glaubst, dass Du durchs Selberkompilieren irgendwelche Vorteile hast, dann kann ich Dir nicht helfen. Es ist reine Zeitverschwendung!

Falls Du es trotzdem machen willst, dann verwende keine Binärdistribution, sondern Gentoo mit "-O3 -funroll-loops -ffast-math -fomit-frame-pointer". Wundere Dich dann allerdings nicht darüber, dass das System 500 MB Festplattenplatz zusätzlich braucht.

PS: http://funroll-loops.org/

Nochwas: Lass Dich nicht durch irgendwelche "-msse"- oder "-fexpensive-optimizations"-Flags irgendwelcher Gentooler verscheißern. Die sind nämlich alle bereits in "-O2" enthalten, wie ein kurzer Blick in die man page des GCC verrät.
 

ne-t-ux

Newbie
So langsam muss ich aufpassen das ich die Motivation nicht ganz verliere. War bestimmt etwas uebermotiviert. Die exakt gleichen Pakete kommen nicht raus es schwankt mal 2kb hier mehr mal da. Doch wer weiss ob das relevant ist. Nebenbei les ich auch weiter die Dokumentationen und man-pages.
Ich ging davon aus das beim selbstkompilieren noch optionen fuer i386 maschinen mit aktiviert werden; zumindestens die die man nicht mehr fuer aktuell und noetig haelt da man dvon ausgehen kann das die Mehrheit >=i586 besitzt. Und dann tut mir die Wahrheit hier auch nicht so weh.

@ traffic Ich meinte die FLAGS bei denen ich einstelle kann --with-XXX etc.

Danke euch beiden fuer die merkenswerten Tipps. Gruss Steve
 

ne-t-ux

Newbie
hab ein ersten "Vorgeschmack". 25% Einsparung in der RAM und Swap Verbrauch.
Jedoch tat sich eine neue Frage auf, welche ich mir nicht selbst beantworten kann. Existiert ein Befehl der mir ausgibt welche Quelle ich dafuer brauche?
Gruss Steve
 
ne-t-ux schrieb:
hab ein ersten "Vorgeschmack". 25% Einsparung in der RAM und Swap Verbrauch.
:roll: oder :lol:, das ist hier die Frage...

25% Einsparung durch einfaches Neukompilieren mit genau denselben Optionen. Das nennt man wohl Placebo.

Sag mal, Dir ist schon klar, wie der GCC funktioniert? Wenn Du dasselbe Programm auf zwei Rechnern aus demselben Source-RPM kompilierst, dann sind die fertigen Binaries gleich. Du verschwendest gerade Deine Zeit, indem Du Dir irgendwelche Effekte einbildest, die einfach unmöglich sind.

Die +/- 2 kb bei einigen Paketen sind Fliegendreck, das können z.B. einfach Unterschiede in den RPM-Headern sein (im RPM-Header werden so Sachen wie das Build-Datum und der Hostname des Build-Rechners gespeichert, die zu unterschiedlichen Zeiten und auf unterschiedlichen Rechnern natürlich auch unterschiedlich lang sein können).
 

ne-t-ux

Newbie
Nunja, ich habs gemacht. Du auch schon, wenn nicht bitte ich Dich zu antworten oder nicht. Ich will hier nicht irgendwie komisch rueberkommen, darauf hab ich keinen Bock, da kann man andere Dinge tun.
Meine konkrete Frage war eigentlich nur die nach einem moeglichen Befehl der mir ausgibt welche Quelle ich zur Kompilierung dieses Paketes brauche.
Zur anderen Thematik kann ich mir nur einiges herleiten, deswegen bin ich auch vorsichtig. Doch wenn ich mir vorstelle das durch configure mein System gecheckt wird, dann kann ich mir auch denken das er dann einiges auslaesst. Sonst waere dieser Vorgang ja 100% sinnlos. Und mit nem i386 Pentium ii Thinkpad 600, da kann so einiges wegbleiben, oder?
 

}-Tux-{

Hacker
ne-t-ux schrieb:
Meine konkrete Frage war eigentlich nur die nach einem moeglichen Befehl der mir ausgibt welche Quelle ich zur Kompilierung dieses Paketes brauche.
irgendwie verstehe ich diese Frage nicht.

ne-t-ux schrieb:
Doch wenn ich mir vorstelle das durch configure mein System gecheckt wird, dann kann ich mir auch denken das er dann einiges auslaesst. Sonst waere dieser Vorgang ja 100% sinnlos. Und mit nem i386 Pentium ii Thinkpad 600, da kann so einiges wegbleiben, oder?
Das configure script checkt meistens nur ob du alles libraries, die zum Bauen des Programms benötigt werden vorhanden sind und bereitet die source für's "make" vor..
Bei manchen Paketen kannst du auch noch dem configure script mitteilen, ob du das Programm mit bestimmten Features compilieren willst...


}-Tux-{
 

ne-t-ux

Newbie
Hey Tux,

es gibt einige Pakete die "uebrig" bleiben. Pakete die aus anderen Quellen entstanden ist. Wie z.B libstdc++* aus gcc oder mit und durch die gcc.src. nun denk ich mir es gibt vielleicht einen Befehl "what_src libstdc++" als Beispiel.

War ich besser, ;) Schoenen Gruß an euch.
 

}-Tux-{

Hacker
ne-t-ux schrieb:
Hey Tux,

es gibt einige Pakete die "uebrig" bleiben. Pakete die aus anderen Quellen entstanden ist. Wie z.B libstdc++* aus gcc oder mit und durch die gcc.src. nun denk ich mir es gibt vielleicht einen Befehl "what_src libstdc++" als Beispiel.

War ich besser, ;) Schoenen Gruß an euch.
ach du willst wissen welches rpm zu welchen src.rpm gehört?

Code:
rpm -q --qf '%{SOURCERPM}\n' paket
 
Oben