Size of executable (linked to wxwidgets dynamically vs. static)
Size of executable (linked to wxwidgets dynamically vs. static)
I'm a newbie to c:b and wxwidgets and up to now I developped with MS's VS.
Building my first GUI "Hello world" (dynamically linked to the wx-libs)
it produces a relase exe of about 500kB.
(Which is pretty much compared to the exe sizes that VS produces with MFC).
My question:
If I want to build my exe with wx-libs included (= statically linked),
I will have to build the wx-libs by myself (no prebuild binaries for download), right?
And second:
What size will a simple GUI-Hello-World be with that?
(I fear it will be something around 1M+)
(If it would be as large, it would be unusable for my cases.)
Building my first GUI "Hello world" (dynamically linked to the wx-libs)
it produces a relase exe of about 500kB.
(Which is pretty much compared to the exe sizes that VS produces with MFC).
My question:
If I want to build my exe with wx-libs included (= statically linked),
I will have to build the wx-libs by myself (no prebuild binaries for download), right?
And second:
What size will a simple GUI-Hello-World be with that?
(I fear it will be something around 1M+)
(If it would be as large, it would be unusable for my cases.)
Re: Size of executable (linked to wxwidgets dynamically vs. static)
A statically linked "minimal" sample without any dependencies will be around 2.8-3m. There are a few tricks to get lower, but you'll never get near 1m (unless you use an EXE-packer like UPX).
Use the source, Luke!
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Uffzz...!
But why is this SO large?
I mininal GUI statical linked MFC exe with VisualStudio is about 100k.
Doesn't the gcc linker strip the lib code that is not needed?
I think this is a very important disadvantage ...
But why is this SO large?
I mininal GUI statical linked MFC exe with VisualStudio is about 100k.
Doesn't the gcc linker strip the lib code that is not needed?
I think this is a very important disadvantage ...
Re: Size of executable (linked to wxwidgets dynamically vs. static)
I don't know why you need a small executable so badly ( does it have to fit on 1.44mb floppy?), but i'm pretty sure most people don't care.I think this is a very important disadvantage ...
Use the source, Luke!
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Well the hw environment I'm working at requires it ...
But back to my question:
Maybe I'm just kind of "spoiled" by the "pure windows" stuff.
Maybe not wxwidgets is large, but MFC is small because it needs no "layer" for platform independency?
As I don't need platform independency now - maybe should look for a free gui lib for windows
that does with mingw/ codeblocks (any suggestions?)
But back to my question:
Maybe I'm just kind of "spoiled" by the "pure windows" stuff.
Maybe not wxwidgets is large, but MFC is small because it needs no "layer" for platform independency?
As I don't need platform independency now - maybe should look for a free gui lib for windows
that does with mingw/ codeblocks (any suggestions?)
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Can't you just stay with MFC then?As I don't need platform independency now - maybe should look for a free gui lib for windows
The only lightweight alternative i know is FLTK. http://www.fltk.org
Use the source, Luke!
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Thank you for the hint to FLTK ... this looks promising.
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Wherever it is good or bad, in 2017 no one sane cares about whether the size a desktop applications is 100 kB or 3 MB.
The size of "minimal" executable is not a good metric. You need to know the size of the executable with your features in and the "minimal" executable sizes may not properly reflect the fully-featured application size.
IIIRC, one of the reasons for the large initial size of wxWidgets application is (that on Windows) huge image libraries (JPEG, TIFF, GIF, PNG , PCX...) as well the ZIP library are linked in statically (all needed by wxImage). If you do not need this functionality, you can turn it off when buildng wxWidgets (via USE_xx, see WXWIN/include/MSW/setup.h for the options). And there are other things also not in the MFC linked in by default.
The size of "minimal" executable is not a good metric. You need to know the size of the executable with your features in and the "minimal" executable sizes may not properly reflect the fully-featured application size.
IIIRC, one of the reasons for the large initial size of wxWidgets application is (that on Windows) huge image libraries (JPEG, TIFF, GIF, PNG , PCX...) as well the ZIP library are linked in statically (all needed by wxImage). If you do not need this functionality, you can turn it off when buildng wxWidgets (via USE_xx, see WXWIN/include/MSW/setup.h for the options). And there are other things also not in the MFC linked in by default.
Re: Size of executable (linked to wxwidgets dynamically vs. static)
So, even if I don't use any imaging code - but only GUI building - then the linker will add these huge libraries to my application?PB wrote: IIIRC, one of the reasons for the large initial size of wxWidgets application is (that on Windows) huge image libraries (JPEG, TIFF, GIF, PNG , PCX...) as well the ZIP library are linked in statically (all needed by wxImage). If you do not need this functionality, you can turn it off when buildng wxWidgets (via USE_xx, see WXWIN/include/MSW/setup.h for the options). And there are other things also not in the MFC linked in by default.
Re: Size of executable (linked to wxwidgets dynamically vs. static)
I think it is not important where the "bloat" comes from. If you are really interested in that you can look at size of all those {core|base}_*.obj files (assuming you are using MSVC, they are in WXWIN/build/MSW/vc_lib/mswu folder) that comprise the two basic wxWidgets libraries. There's a lot of supporting code that is always linked in once you use the basic wxWidgets classes. You can also ask in the wx-users discussion group which is frequented by wxWidgets developers, or better yet - you can look up the answer to the question: IIRC there is already at least one such thread, although not very recent.
I took a brief look at FLTK. It seems to manage to create much smaller executables (32-bit release non-cairo) which is somewhat impressive considering it actually uses its own controls instead of the native ones. Even their GUI designer (Fluid) is smaller than wxWidgets minimal sample. OTOH, not having a native look may be quite a disadvantage to some. I also have no idea how the features compare.
As I said above, I believe choosing a toolkit based on resulting executable size is not a good idea but if you need that, wxWidgets probably is not for you.
I took a brief look at FLTK. It seems to manage to create much smaller executables (32-bit release non-cairo) which is somewhat impressive considering it actually uses its own controls instead of the native ones. Even their GUI designer (Fluid) is smaller than wxWidgets minimal sample. OTOH, not having a native look may be quite a disadvantage to some. I also have no idea how the features compare.
As I said above, I believe choosing a toolkit based on resulting executable size is not a good idea but if you need that, wxWidgets probably is not for you.
Re: Size of executable (linked to wxwidgets dynamically vs. static)
Hi,
Like already said you can customize the build of the library by turning off the features you won't need. The the resulting executable will be smaller.
But it was also said that you need to actually build the binary you will use and see what the size will be for that binary.
Or you can just disregard C::B and work with MSVC + wxWidgets, whatever version of MSVC you currently have.
The choice is up to you.
Thank you.
Like already said you can customize the build of the library by turning off the features you won't need. The the resulting executable will be smaller.
But it was also said that you need to actually build the binary you will use and see what the size will be for that binary.
Or you can just disregard C::B and work with MSVC + wxWidgets, whatever version of MSVC you currently have.
The choice is up to you.
Thank you.