Platzsparend statisch linken

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
hennes@debian
Beiträge: 465
Registriert: 18.01.2005 02:11:40
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schweiz - Kanton St. Gallen
Kontaktdaten:

Platzsparend statisch linken

Beitrag von hennes@debian » 18.10.2005 15:44:24

Hallo!

Ich bin in der Firma daran ein Embedded Powerpc Entwickler-Toolchain zusammen zu stellen. Wir benötigen vor allem Java, mittels GCJ compilliert.

Nun das Problem: Die libgcj benötigt ca. 16MB was für ein Embedded System nicht gerade ideal ist. Gibt es eine Möglichkeit Programme statisch zu linken ohne das die nicht benützten Funktionen (Swing/AWT usw...) mit einkompilliert werden?

Momentan wird das statisch gelinkte Programm ca. 7MB gross, obwohl es nichts enthält. Im Executable finde ich auch div. verweise auf nicht benutzte Bibliotheken.

Code: Alles auswählen

class test{
        public static void main(String[] args){
                System.out.println("test");
        }
}

Code: Alles auswählen

gcj-4.1.0-cvs -O3  test.java -o test --main=test -static
strip test
ls -lh test
-rwxr-xr-x  1 hd hd 7.3M 2005-10-18 15:42 test
Gruss Hannes

Benutzeravatar
peschmae
Beiträge: 4844
Registriert: 07.01.2003 12:50:33
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: nirgendwo im irgendwo

Beitrag von peschmae » 18.10.2005 16:00:18

Ich weiss nicht wieviel das hilft aber:

(*) strip -s <datei> [Edit]Oops, das machst du ja schon ;)[/Edit]
(*) -Os statt -O3 verwenden (ersteres guckt auf kleinen Code, letzteres optimiert so gut wie möglich - dazu gehören auch Sachen wie loop-unrolling was den Code vergrössert)
(*) upx-ucl auf das Executable loslassen - das hilft zumindest Festspeicherplatz sparen, verkleinert das Ding aber nicht für während der Laufzeit

aber eigentlich sollte meines Wissens beim statischen linken schon automatisch nur das mitgelinkt werden was auch wirklich benötigt wird, und nicht alles.

Von dem her ists auch möglich dass du die Grösse nicht mehr wirklich viel runterbringst (eventuell fährst du da am Ende mit einem Java Interpreter für Embedded (jamvm oder so - k.A.) + Jar besser als mit nativ kompiliertem Zeugs)

MfG Peschmä
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy

hennes@debian
Beiträge: 465
Registriert: 18.01.2005 02:11:40
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schweiz - Kanton St. Gallen
Kontaktdaten:

Beitrag von hennes@debian » 18.10.2005 16:37:13

Hmm...

1. Ohne strippen ist das Programm 22MB gross :evil:
2. -Os optimiert meinen Programmcode... Das gibt bei einer Zeile ca. 0kb... ev. müsste mann libgcj neu compillieren mit -Os
3. Später wird das ganze sowiso auf einem cramfs laufen, also nützt komprimieren nicht viel...
4. Eine JVM ist leider zu langsam...

Naja, es scheint so als würde immer die ganze libgcj dazugelinkt, ich kann mir nicht vorstellen das der Java Starter und System.out schon 7.3MB speicher benötigen. Als Versuch habe ich mal ein Programm das Swing benötigt erstellt: Auch 7.3MB

Kennt jemand eine Lösung? Oder gibts ein Howto wie ich die libgcj kleiner bekomme indem ich Klassen enferne? Hab keine lust von Hand 50'000 zeilige Makefiles zu ändern...

Dieser Dialog zeigt mein Problem schön:
http://gcc.gnu.org/ml/java/2001-03/msg00181.html
Nur ist er aus 2001 und ev. hat sich mal was geändert... -Wl,--gc-sections verkleinert mein Programm gerade mal um 5KB...

Benutzeravatar
peschmae
Beiträge: 4844
Registriert: 07.01.2003 12:50:33
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: nirgendwo im irgendwo

Beitrag von peschmae » 18.10.2005 17:16:08

hennes@debian hat geschrieben: 1. Ohne strippen ist das Programm 22MB gross :evil:
*groehl* ;)
2. -Os optimiert meinen Programmcode... Das gibt bei einer Zeile ca. 0kb... ev. müsste mann libgcj neu compillieren mit -Os
Ja. War auch mehr für dann gedacht wenn du dann Code hast.
3. Später wird das ganze sowiso auf einem cramfs laufen, also nützt komprimieren nicht viel...
Ok. Obwohl upx executables sehr stark komprimiert - meist mehr als andere universelle Kompressionsalgorithmen.
4. Eine JVM ist leider zu langsam...
Sicher dass GCJ schneller ist? Ich nehme mal an als eine nur interpretierende JVM schon - aber im Vergleich mit Suns JVM gewinnt der zumindest bei mir nicht wirklich was.
Naja, es scheint so als würde immer die ganze libgcj dazugelinkt, ich kann mir nicht vorstellen das der Java Starter und System.out schon 7.3MB speicher benötigen. Als Versuch habe ich mal ein Programm das Swing benötigt erstellt: Auch 7.3MB
Oh, ok. Dann ist das wohl nur für C/C++ so schlau. Überrascht mich aber weil das ja eigentlich nur ein Frontend ist für Java und ich denke das rausschmeissen erst später geschehen sollte (beim linken?)

MfG Peschmä
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy

hennes@debian
Beiträge: 465
Registriert: 18.01.2005 02:11:40
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Schweiz - Kanton St. Gallen
Kontaktdaten:

Beitrag von hennes@debian » 18.10.2005 17:47:39

peschmae hat geschrieben:
3. Später wird das ganze sowiso auf einem cramfs laufen, also nützt komprimieren nicht viel...
Ok. Obwohl upx executables sehr stark komprimiert - meist mehr als andere universelle Kompressionsalgorithmen.
Naja, ein Versuch ists wert... Mal ausprobieren!
4. Eine JVM ist leider zu langsam...
Sicher dass GCJ schneller ist? Ich nehme mal an als eine nur interpretierende JVM schon - aber im Vergleich mit Suns JVM gewinnt der zumindest bei mir nicht wirklich was.
Das Target ist ein PowerPC 823 / 50MHz mit 16MB Ram und 16MB Flash... Sun's JVM benötigt schon prinzipiell 32MB Ram... Und die KVM hat glaube ich kein JIT...
Oh, ok. Dann ist das wohl nur für C/C++ so schlau. Überrascht mich aber weil das ja eigentlich nur ein Frontend ist für Java und ich denke das rausschmeissen erst später geschehen sollte (beim linken?)
Dachte ich auch... Aber sieht nicht so aus... Naja, in diesem fall arbeite ich mich mal in Automake usw.. ein und versuche eine libgcj zu erstellen die nur die nötigsten Files enthält. Wenn dann sonst noch was benötigt wird, kann ich die Sourcefiles dann ja einfach in den Projektroot kopieren...

Gruss Hannes

Antworten