4. [wxWidgets] Größe der Exe...

[wxWidgets] Größe der Exe...

  • P
    Mod

    In den DLLs würden dann die wxWidgets Klassen stecken...

    0
  • C

    Hi,

    Ja und was sollte sich in den DLL's befinden? Der wxWidgets Code, der dann zur Laufzeit ausgeführt wird?

    Diese Form des linkens ist wohl auch eher für eine Vielzahl von wx-Projekten auf ein und demselben Rechner sinnvoll, damit nicht jede Exe die gleichen statischen Libs enthält...aber das Argument "man kann nicht alles haben" stimmt schon und ich bin mit 440 kB auch gar nicht mal so unzufrieden, wenn da schon das meiste mit drin ist.
    Es würde mich nur mal interessieren, ob es bei wxWidgets oder anderen Toolkits in Kombination mit verschiedenen Compilern Pläne gibt, so eine Art optimales Funktions-Level-Linking zu betreiben, auch wenn es dabei zu erheblichen Verzögerungen beim Kompilieren kommt...dann könnte man zum Testen immer ohne Optimierung kompilieren und wenn man die finale Exe dann veröffentlichen will, lässt man den Compiler 5 Stunden rechnen und hat dafür wirklich nur die Funktionen als Maschinencode, die man auch aufruft. Das Ergebnis müsste dann doch ähnlich klein sein, als wenn ich mit Win32API programmiere und dort statisch linke (ich setze mal voraus, dass das Programm alles mitbringen sollte, um auf Maschinen von 95 bis XP autark lauffähig zu sein).

    0
  • M

    phlox81 schrieb:

    In den DLLs würden dann die wxWidgets Klassen stecken...

    Also wenn ich dich richtig verstehe, müsste man sich dann den Quelltext der jeweils benötigten wxWidgets Klassen besorgen, und diesen dann in ne DLL verpacken? Wäre aber wirklich umständlich... Bleibt aber wohl kein anderer Weg mehr offen.

    0
  • P
    Mod

    Nein -.-

    Du kannst wxWidgets als Library sowohl statisch .a/lib als auch dynamisch (.dll/.so) kompilieren.
    Damit wird dann die wxWidgets Library nicht in die Exe compiliert, sondern dynamisch dazu gelinkt.
    Dies ist auch notwendig, wenn man z.b. Plugins benutzen will.

    0
  • P
    Mod

    cpphonk schrieb:

    Hi,

    Ja und was sollte sich in den DLL's befinden? Der wxWidgets Code, der dann zur Laufzeit ausgeführt wird?

    Diese Form des linkens ist wohl auch eher für eine Vielzahl von wx-Projekten auf ein und demselben Rechner sinnvoll, damit nicht jede Exe die gleichen statischen Libs enthält...aber das Argument "man kann nicht alles haben" stimmt schon und ich bin mit 440 kB auch gar nicht mal so unzufrieden, wenn da schon das meiste mit drin ist.
    Es würde mich nur mal interessieren, ob es bei wxWidgets oder anderen Toolkits in Kombination mit verschiedenen Compilern Pläne gibt, so eine Art optimales Funktions-Level-Linking zu betreiben, auch wenn es dabei zu erheblichen Verzögerungen beim Kompilieren kommt...dann könnte man zum Testen immer ohne Optimierung kompilieren und wenn man die finale Exe dann veröffentlichen will, lässt man den Compiler 5 Stunden rechnen und hat dafür wirklich nur die Funktionen als Maschinencode, die man auch aufruft. Das Ergebnis müsste dann doch ähnlich klein sein, als wenn ich mit Win32API programmiere und dort statisch linke (ich setze mal voraus, dass das Programm alles mitbringen sollte, um auf Maschinen von 95 bis XP autark lauffähig zu sein).

    Kurz nein.
    Lang:
    In deinem Win Api Programm sind auch nicht alle komponenten kompiliert, die du benutzt, da ist schon vieles bei Windows dabei, und wird
    über verschiedene DLLs zur Verfügung gestellt. Auch wenn du statisch wxWidgets kompilierst, wird nicht einfach die statische Lib
    in die Exe eingebunden sondern nur den Teil, den du verwendest. Zu mal die WinApi ja weitestgehend C Code und kein Objektcode von C++ ist.
    wxWidgets aber ist nur Objektorientiert, und bringt auch noch den Overload eines eigenen Frameworks mit. Da ja für wxFrame nicht nur
    wxFrame gelinkt wird, sondern auch alle seine Parentklassen.

    0
  • M

    Achso, sorry wusste ich nicht. Hm ja, ist in der Tat eine sinnvolle Alternative, bei vielen Programmmodulen.

    0
  • B

    soviel ich weiß kannst du die wxWidgets ja auch nur mit den Komponenten
    kompilieren die du brauchst (natürlich dürfen auch hier nicht die
    Abhängigkeiten der einzelnen Klassen nicht ignoriert werden )... das
    spart Library-platz...

    0
  • M

    Um das geht's uns doch in diesem Thread 😉 Und wie möchtest du das machen?

    0
  • B

    ich weiß das nur unter linux...da kann man das im konfigurations-script
    angeben...(--enable-bla usw.) du kannst allerdings auch alle
    Module der wxWidgets einzeln kompilieren, also jedes in eine *.lib bzw
    *.dll oder *.so und es dann einzeln dazu linken statisch oder dynamisch,
    statt alles monolithisch in eine library zu kompilieren...viele, viele
    möglichkeiten...

    0
  • F

    Unter Visual C++ 6.0 habe ich wxWidgets 2.6.3 in der Eingabeaufforderung als DLL kompiliert:

    - cd \Programme\Microsoft Visual Studio\VC98\bin
    - vcvars32
    - cd \wxWidgets-2.6.3\build\msw
    - nmake -f makefile.vc BUILD=debug SHARED=1 MONOLITHIC=1 USE_XRC=1 UNICODE=0
    - nmake -f makefile.vc BUILD=release SHARED=1 MONOLITHIC=1 USE_XRC=1 UNICODE=0

    Das Makefile makefile.vc musste ich anpassen, da der Linker ohne eine spezielle Option nur bis zu einer bestimmten Größe linkt:

    Im Makefile nach " !if "(MONOLITHIC)" == "1" && "(SHARED)" == "1" " suchen und in dem 2. gefunden Abschnitt folgende Linker-Optionen verwenden:

    link /DLL /NOLOGO /INCREMENTAL:NO /OUT:$@

    (Die Option "/INCREMENTAL:NO" habe ich hinzugefügt)

    Die Release-Version der DLL ist ca. 4,6 MB groß, und die Debug-Version ist ca. 5,5 MB groß.

    Ein Test-Programm mit einem Fenster wird 64 kByte groß.

    0
Anmelden zum Antworten