Ich hab mir was ausgedacht, um die Größe von exes kleinzuhalten...

[axeljaeger]

Wenn man eine Headerdatei inkludiert, aus der man aber nur eine Funktion braucht, finde ich, ist es doch überflüssig, die ganze Headerdatei zu inkludieren. Wenn man einfach den Funktionsprototyp schön in extern "C" einklammert, kann man eine Funktion nutzen, ohne den ganzen Header zu inkludieren.

Was haltet ihr von diesem Gedanken? Mist? Genial? Gabs schonmal?

[Lin728]

strip -s exe

Macht genau das selbe , wirft alle unbenötigten symbole raus.

[axeljaeger]

ach ja, das kannte ich noch gar nicht. Geht das auch mit C++? Wenn man dann noch den UPX drüberlaufen lässt, kann man ja richtig was sparen. Wird das auch in der Praxis, etwa bei den Distributionen eingesetzt?

[Jasper]

Original geschrieben von axeljaeger
ach ja, das kannte ich noch gar nicht. Geht das auch mit C++? Wenn man dann noch den UPX drüberlaufen lässt, kann man ja richtig was sparen. Wird das auch in der Praxis, etwa bei den Distributionen eingesetzt?

bei rpm läuft bei der erstellung der pakete per default immer ein strip über die binaries. insofern enthalten rpm-basierte distributionen nur gestrippte binaries.

-j

[peschmae]

upx ist afaik eher unüblich, wieso weiss ich auch nicht, werden doch die Programme viel kleiner und nicht wirklich langsamer

MfG Peschmä

[axeljaeger]

ich fin upx auch ziemlich cool: Mitttels dreier Methoden habe ich ih jetzt eine 38kb Qt-Exe auf 9.6kb runtergeknechet.

1. Tipp von Prolinux, das man C++ Programme nicht gegen libstdc++ linken muss
2. strip -s
3. UPX

Das erste bringt jetzt von der Größe nichts, ich finde es aber sehr elegant, wenn man mit wenig shared-libs auskommt

[Lin728]

was ist denn UPX und wo gibts bitte den Trick mit ohne libstc++ zu linken?
Geht das auch mit FLTK, QT

[peschmae]

upx = Ultimate Packer for eXecutables

http://upx.sourceforge.net

komprimiert Executables für Windows, Linux und wasweissich sehr stark. Die Dekompression ist sehr schnell, d.h. nicht spürbar und soll in spezialfällen sogar schneller sein, da weniger von der HD geladen werden muss

Kompressionsraten: zwischen 30 und 50 % (der Originalgrösse) bleiben übrig

MfG Peschmä

[axeljaeger]

Hier steht, wie das geht:
http://www.pl-berichte.de/t_system/c++-libc.html

Aber wie gesagt, es bringt dir von der Größe her nichts, nur meiner Meinung nach ist es eleganter. Vielleicht bringt es ja vom Speed her was?

Edit: Ja, das geht mit Qt und es müsste auch mit FLTK gehen. Du musst aber auf RTTI und Exceptionhandling verzichten, was für mich zu verschmerzen ist. Ich hab auch noch nicht gesehen, das dieses in der Praxis eingesetzt wurde. Qt jedenfalls verwendet diese Funktionen nicht

[Lin728]

Danke für die Links!

[peschmae]

genau dazu brauch ichs auch :D

MfG Peschmä

[Lin728]

Grüssi!

Anscheinend funktioniert mit upx keine shared libraries zu laden...

Hat das wer zum gehen gebracht?

[axeljaeger]

was meinst du genau? Ich konnte ja bspw. die Qt-Lib benutzen. Oder meinst du, zur Laufzeit eine .so aufmachen? Das hab ich noch nicht ausprobiert, ich weis nur, das man eine UPX'ed exe nicht mehr mit ldd zu den Abhängigkeiten befragen kann

[Lin728]

Nun, wenn ich ein executable packe, dass shared-libs enthält, stürzt es beim start mit einem segmenattion-fault ab.

Ach ja, noch was: Da steht, dass es auch .dll-s packen kann, aber ist es nicht auch mögcli shared-libs zu packen?

[axeljaeger]

also shared libs hab ich damit noch nicht gepackt und ich kann mir auch nicht vorstellen, dass das geht. Und ja, so habe ich es gemacht: upx --best <binary>
ging wunderbar.

Edit: Wie wär's denn mal, wenn du die stable (1.24) benutzt?

[Lin728]

Nein, ganz einfach ein Binary dass z.B. dynamisch gegen die libc.so.6 gelinkt ist.
Da bekomm ich beim starten dann nen segfault.
Bei statisch gelinkten Sachen gehts wunderbar!

hast du schon einmal dynamisch gelinkte binaries damit gepackt?

[axeljaeger]

Ich nehme mal an, jedes Programm, was ich mit Qt schreibe ist dynamisch gegen libqt-mt.so gelinkt. Und die gehen gut.