✔ Striptease fuer Binaries und Libraries

Dennis Wronka

Dennis Wronka

Soulcollector
Bei der Installation von Linux from Scratch (und auch meinem EasyLFS) werden ja am Ende noch die Binaries und Libraries von Debug-Symbolen befreit um etwas Speicherplatz zu gewinnen.
Ich hab nun mal durch die Hilfe von strip geschaut und dort den Parameter --strip-unneeded gefunden, welcher fuer mich ganz interessant aussieht, und scheinbar weniger drastisch als --strip-all.
Ich habe jetzt grad mal kurz was rumgetestet und durch strip --strip-unneeded ist das Binary von Scorched3D (um mal ein gutes Beispiel zu nennen) von 25 auf 2.8MB zusammengesackt. Das find ich schon nicht schlecht.
/usr/local/bin ist von knapp 80 auf 30MB geschrumpft. /usr/bin (das hab ich sicherheitshalber erstmal mit einer Kopie probiert) wuerde von 600 auf ca. 250MB fallen.

Als naechstes werd ich es mal an einer Kopie meines KDE-Verzeichnisses probieren, welches ungestrippt mit 1.1GB daherkommt.

Jetzt wollte ich hier einfach mal nachfragen ob man mit irgendwelchen Komplikationen rechnen kann/sollte/muss wenn man mit --strip-unneeded die Dateien schrumpfen laesst oder ob das sicher ist. Eigentlich sollte es ja sicher sein, denn sonst wuerde dies wohl nicht im LFS-Buch stehen. Andererseits werden dort ja auch nur Debugging-Symbole entfernt, bei --strip-unneeded aber wohl doch etwas mehr.

Naja, vielleicht hat da jemand Erfahrungs-/Leidensberichte fuer mich.
Ich werd auf jeden Fall mal etwas rumprobieren, und fuer meine Bins und Libs in /usr/local/bin, /usr/local/sbin und /usr/local/lib ist es nun eh zu spaet (Probleme scheint es aber bisher keine zu geben).

Nachtrag: KDE ist mittlerweile fertig gestrippt (ich haette vielleicht nicht alles per find durchsuchen lassen sollen sondern ledliglich bin, sbin und lib ;) ), aber dabei wurden nur 100MB eingespart, was ja nicht ganz so der Bringer ist.
Ich werd mal schauen was sich bei /usr/lib so einsparen laesst (natuerlich auch erstmal an einer Kopie).
 
Unneeded klingt so, als werden evtl. unreferenzierte Symbole (oder variablen) entfernt, die zwar initialisiert sind, aber ennoch unbenutzt sind, weil die Programmierung da etwas unsauber war. Ist aber nur eine Idee, ich geb da keine Garantie drauf ;)

z.B. so:
die variable wert belegt sinnlos 1024 byte(Zeichen)
Code: 
Vorher:
void myFunction() {
  char wert[1024];
}

Nachher:
void myFunction() {
}
 
Aber wuerde sich da nicht hauptsaechlich auf die Groesse im Arbeitsspeicher auswirken als auf die Groesse des Binaries auf der Festplatte? Natuerlich macht das auch im Binary einen Unterschied, aber der duerfte hier dann wohl nicht so gravierend sein.

Und ich glaub auch nicht, dass Scorched3D so mies geschrieben ist, dass vom Binary 22MB weggestrippt werden koennen nur weil unnoetig Variablen deklariert werden.
 
Ich weiss es nicht SOOO genau *zugeb* - ist ja auch nur eine Vermutung. Dass die ganze RAM-Intensiv werden kann, ist klar, jedoch wird auch im Binary Space reserviert, wenn eine Variable zB. belegt ist ... um beim Beispiel zu bleiben: angenommen, du belegst diese Variable "wert" mit 1024 zeichen, so wird dieser Speicher auch im Binary verwendet, da die Variable ja irgendwoher wissen muss, mit was sie belegt ist ;). Was aber noch sein kann ist, wenn ich zB eigene DEBUG-meldungen generiere, indem ich zB folgendes tue:
Code: 
void myfunction() {
#ifdef __DEBUG__
cout << "DEBUG: Testing OS" << endl;
#endif

#ifdef __win32__
  cout << "Windows32 is not supported" << endl;
#else
#ifdef __linux__
  cout << "You are using Linux - the good system" << endl;
#endif
}
Wenn man das nun mit gcc kompiliert, und dazu die Option "-__DEBUG__" einschaltet,
reserviert das Programm im Heap sowie im Binary den passenden Speicher. Bei Konsolen-Ausgaben können das schon einige Bytes sein, da die libcrt doch etwas anspruchsvoll ist.

ABER:
WAS genau das Binary mit dem mist macht, wenn all das durch "strip" weg ist, weiss ich nicht ;)

LG
Andy
 
Hallo,

strip --strip-unneeded entfernt alle globalen Symbole die in der aktuellen Objektdatei nicht referenziert werden, d.h. willst du dein System schrotten dann kannst du strip --strip-unneeded auf shared Libs und Objektdateien anwenden, weil man später nicht mehr gegen diese Linken kann bzw wenn du ein Programm hast welches die Symbole aus der Bibliothek benutzen will und man das Programm gegen die gestrippte Bibliothek/Objektdatei linken will, bekommt man unaufgelöste Symbole...

Bsp.:

libMyLib.so enthält:
Code: 
//foo wird sonst nirgends referenziert in libMyLib.so => strip --strip-unneeded entfernt foo
int foo()
{
}

Folgendes Programm:
Code: 
int main()
{
    foo();
}

nach einem strip --strip-unneeded libMyLib.so bekommt man beim übersetzen des Programms folgenden Fehler:
Code: 
redwing@euklid:~ $ gcc main.c -lMyLib
/tmp/ccQ5LuNh.o: In function `main':
test2.c:(.text+0x12): undefined reference to `foo'
collect2: ld returned 1 exit status
redwing@euklid:~ $

Also es könnte durchaus Sinn machen strip --strip-unneeded auf Binarys anzuwenden, aber von der Anwendung auf Shared Libraries würd ich lieber die Finger lassen :)

Gruß,
RedWing
 
Zuletzt bearbeitet:
Na das ist doch mal eine richtig brauchbare Aussage. :)
Nun gut, /usr/local/lib ist dann jetzt wohl mehr oder weniger unbrauchbar, aber dort liegt auch nicht so wahnsinnig viel.
Bei /usr/lib werd ich dann wohl eher mit --strip-debug arbeiten, das sollte ja kein Problem darstellen, oder?
Und die Binary-Verzeichnisse kann ich dann ja weiterhin mit --strip-unneeded bearbeiten.

Auf jeden Fall mal vielen Dank fuer die Info und das erklaerende Beispiel.
 
Gut gut.
Bisher laufen zwar auch weiterhin alle Programme in /usr/local, z.B. Nessus und Firefox ohne Probleme, aber ich denk es ist doch besser auf Nummer sicher zu gehen als ein paar 100MB mehr Speicher zu haben, auch wenn ich Plattenplatz zur Zeit gut gebrauchen kann.

Ich denke ich kann dann nun, aufgrund der hier gewonnenen Informationen den Thread mal als erledigt markieren sodass jemand der vielleicht irgendwann mal auf die gleiche Idee kommt gleich hier rein schauen kann. ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück