stripping libraries läuft nicht ganz richtig

µRaCoLi

Mitglied
Mitglied seit
22 Sep 2005
Beiträge
239
Punkte für Reaktionen
0
Punkte
0
Code:
...
stripping unstripped AVM binaries
done.
...
$ file build/modified/filesystem/lib/libpthread-0.9.28.so 
build/modified/filesystem/lib/libpthread-0.9.28.so: ELF 32-bit LSB shared object, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Wieso wird diese library nicht gestrippt?
 
Vielleicht weil es eine Library ist und nicht ein ausführbares Programm.
Vielleicht weil etwas in Deiner nicht näher genannten Ausgangsfirmware anders ist als früher.
 
Vielleicht weil es eine Library ist und nicht ein ausführbares Programm.
Hab in fwmod nachgeschaut und es werden nur ausführbare Dateien (find -perm +100) überprüft. libpthread-0.9.28.so hat 0644, jedoch gibt es viele Libraries mit 0777, warum auch immer.
Vielleicht weil etwas in Deiner nicht näher genannten Ausgangsfirmware anders ist als früher.
Als Ausgangsfirmware benutze ich FBF 06.04.30, dies hat sich schon lange nicht mehr geändert. Vielleicht irre ich mich ja auch, aber ich meinte, dass früher etwas gestrippt wurde...
 
Generell sind execute-Rechte nicht notwendig bei Libraries, wie man schon daran sieht, daß diese Library funktioniert. Ich weiß nicht, ob die Einschränkung bei find schon immer war oder nicht.

Wenn es übrigens Libraries von Freetz mit Rechten 777 gibt, sollte man das sicherheitshalber ändern.
 
In der Original-FW gibts auch Libraries mit 777. Ich denke, dass es eher ein kosmetisches problem ist, da das Dateisystem ro ist.
Zurück zur eigentlichen Frage, warum diese Library nicht gestrippt wird, wo doch andere gestrippt sind. Gibts da Einschränkungen bei den Libraries?
 
Wie Du oben schon festgestellt haben, werden nur Dateien gestrippt, bei denen das Execute-Recht gesetzt ist. Das ist vermutlich eine deutliche Beschleunigung, weil nicht für jede Datei das file-Kommando aufgerufen werden muß. Man könnte aber ohne größere Nachteile auch alle Dateien *.so mit prüfen.

Ich weiß, daß das Dateisystem normalerweise Readonly ist. Wenn man aber usbroot verwendet, dann kann das Dateisystem beschreibbar sein.
 
Alle shared libraries, die per INSTALL_LIBRARY_STRIP in das image eingebunden werden, werden auf 755 gesetzt. Das betrifft die meisten Libraries in Freetz. Die angesprochene libpthread ist Bestandteil der uClibc, die anders in das fertige image integriert wird.
.
Die vorgeschlagene Änderung im fwmod könnte zB so aussehen:
Code:
        for i in `find ${FILESYSTEM_MOD_DIR} ! -name "*.ko" ! -path "*/usr/www/*" ! -path "*/etc/default*" -type f \\( -perm +100 -o -name *.so* \\)`; do
Auf der 7270 wird das image dadurch ungefähr 5kb kleiner.
 
Habe mir jetzt eine Lösung gebastelt:
Code:
for i in `find ${FILESYSTEM_MOD_DIR}/{bin,sbin,lib,usr/{bin,sbin,lib,share/ctlmgr}} -maxdepth 1 -type f`; do
Dies ist auch schneller, da weniger durchsucht wird. Hoffe, dass nichts vergessen wird. Habe hier nur 4mb-Boxen zum Testen.
Vielleicht kann man das Strippen beim Bau der uClibc ausführen, wie auch bei den übrigen Paketen.
Dann könnte man diesen Code früher ausführen, denn so müssen die bereits integrierten Pakete nochmals überprüft werden, ob sie gestrippt werden müssen.
 
Die selbst erstellten Libraries sind bereits gestrippt, siehe auch #7, INSTALL_LIBRARY_STRIP.
Es geht hier hauptsächlich um die Libraries aus dem original Image.
 
@RalfFriedl: Das ist mir völlig klar. Was ist an meinem Post missverständlich?
 
Man kann sich dann das erneute _Checken_, ob man Strippen muss, sparen, denn jetzt ist es so, dass die Pakete/ Bibliotheken gebaut und anschließend gestrippt werden. Danach werden diese ins Image integriert und jetzt werden alle (Original AVM- und Zusatzpakete) nochmal überprüft, ob sie ggf. gestrippt werden müssen.
Daher mein Vorschlag, dass man erst das Image strippt und dann verifiziert gestrippte Zusatzpakete integriert. Dies sollte effizienter sein.
 
Effizienter in welchem Sinn?
Das original Image wird sowieso jedes Mal neu ausgepackt. Ist es effizienter, über das original Image zu gehen, statt über das neu erstellte? Und Libraries oder Programme strippen, die nachher vielleicht sowieso überschrieben werden?
Effizienter vom Aufwand bei der Programmierung?
Wenn die C-Library nicht gestrippt wird, kann man das nachholen, aber was bringt es, das Programm so umzustellen, daß es das Strippen vor dem Überschreiben der Dateien durchführt?
 
Ich denke nicht, dass wir vor dem build stripen sollten, der Zeitaufwand für den Check und das Stripen ist imho minimal (<15 Sekunden), wir könnten natürlich das 'perm +100' noch anpassen, der Vorschlag aus #7 gefällt mir ganz gut.

EDIT:
Hier eine erste Änderung im Trunk, bitte mal prüfen.
Trotzdem sollten wir uns das direkte stripen der uClibc beim build nochmal anschauen.

EDIT:
Die libpthread stammt aus der download-Toolchain und wird nicht extra gebaut, da müsste der Download-Tar geändert werden. Ich werde das olistudent für die nächste toolchain-Revision mit auf den Weg geben.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.