How to build wxwidgets-2.6.3 to work with code::blocks

[ALLs]

How to build wxwidgets-2.6.3 to work with code::blocks?

please help...

thx

[Lukas]

I think more information is needed to know precisely what you are after.

What finally worked for me in win32 was to build it with mingw and set the SHARED=1 and MONOLITHIC=1 flags, then all I had to do was alter the variable within codeblocks for the correct path and put the .dll somewhere useful.

Basically in /build/msw (if i recall correctly)
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1

I do not understand why I could not build the statically linked version though. I could not get around the linker errors, if anyone knows I am interested to hear.

[Didier69]

Hi,

First I installed mingw last version with the candidate option, then I used this wiki page and it worked for me .

[ALLs]

I now build wx2.6.3 with:
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1

and set directories:
compiler:
C:\wxWidgets-2.6.3\include
C:\wxWidgets-2.6.3\contrib\include
C:\wxWidgets-2.6.3\lib\gcc_dll\msw

linker:
C:\wxWidgets-2.6.3\lib\gcc_dll
C:\wxWidgets-2.6.3\lib\gcc_dll\msw

resource:
C:\wxWidgets-2.6.3\include

but I get an error:

-------------- Build: Debug in test ---------------
Linking console executable: bin\Debug\test.exe
C:\Program Files\CodeBlocks\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw26u
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
 
what i must to do? help please...

thx

[Lukas]

The u of  -lwxmsw26u means it's trying to link the unicode version. Check if you have a libwxmsw26 and if so link to that instead.
i.e replace wxmsw26u with wxmsw26 in the build options/linker

[ALLs]

The u of  -lwxmsw26u means it's trying to link the unicode version. Check if you have a libwxmsw26 and if so link to that instead.
i.e replace wxmsw26u with wxmsw26 in the build options/linker

yes, i now deselect enable unicode in wizard and it working :shock:

thx on help...

[Michael]

Hi,

First I installed mingw last version with the candidate option, then I used this wiki page and it worked for me .

Hello,

Or here :

http://forums.codeblocks.org/index.php?topic=1701.0

Best wishes,
Michael

[wittend]

I really like what I see in the Code::Blocks IDE.  I particularly want to use it with WxWidgets.  The combination seems to be just what I need for two high priority projects, and probably for the next generation of some others.

Unfortunately, of the many programming environments that I use, I have never encountered anything like the difficulty I have had attempting to get this combination configured to correctly compile trivial programs.  There is a large amount of well meaning help available,  including the documents on this forum, the Wiki, and the files included with the software.  Unfortunately, they are frequently contradictory, out of date, or simply at odds with the results that I obtain.

I prefer to use up to date, stable software, and I ordinarily avoid the latest beta's.  But both Code::Blocks and its most obvious alternative, Dev-C++ seem to be on a Moebius-strip glidepath to version 1.0.  I'm sure that some of my problems derive from the way wxWidgets is packaged and documented for distribution, as well.  At this point, the only way that I seem to be able to get useful compiles of MinGW/wxWidgets apps is to do manual command line builds in MSYS using the Makefiles built by configure as examples.

I don't believe that my current expectations are exotic.  I just want to be able to design and build straightforward wxWidgets 2.63 apps for (at present) the Win32 environment.  I don't have any reason to want to build Code::Blocks from source, so I have used the installer version.  Once installed, I want to build unicode apps, staticly linked, at least, but DLL-based would be a nice option, and debug versions of both static & DLL based apps would be icing on the cake.

I am currently using:

CodeBlocks that identifies itself on the startup page as: Version 1.0 revision 2061 (gcc 3.4.4 Windows/unicode, build: Feb 22 2006 16:56:26)
mingw32-make -v returns 3.80
The  wxWidgets version that I am compiling indicates that it is 2.63_1
I am not interested in ANSI builds.
I am using an AMD64 based PC running Windows 2003 with 2G ram and ~ 500G of disk, mostly free.

I have installed all the components that are claimed to be required.  I have done this repeatedly after exorcising every trace of previous attempts.  I have done the whole process on two different machines (gotta get a new laptop - 2hrs to build each wxWidgets library set is too long to bear).

The farthest that I have been able to get working with the IDE is to the point where I can create a default wxWidgets app using the template, add nothing to it - just build it, and I get a horror story of linkage errors.  These *appear* to my unaided eye to be due to a fundamental problem with calling convention or some such.  For ex:

mingw32-g++.exe -LD:\bin\CodeBlocks\wx\wxWidgets-2.6.3\lib\gcc_dll -LD:\bin\CodeBlocks\wx\wxWidgets-2.6.3\lib -LD:\bin\CodeBlocks\lib -LD:\bin\CodeBlocks\wx\wxWidgets-2.6.3\lib  -o wxwidgets_static.exe .objs\main.o    -lwinspool -lwinmm -lshell32 -lcomctl32 -lctl3d32 -lodbc32 -ladvapi32 -lwsock32 -lopengl32 -lglu32 -lole32 -loleaut32 -luuid D:\bin\wxWidgets-2.6.3\lib\libwx_mswu-2.6.dll.a D:\bin\wxWidgets-2.6.3\lib\libwxzlib-2.6.a D:\bin\wxWidgets-2.6.3\lib\libwx_mswu-2.6.dll.a D:\bin\wxWidgets-2.6.3\lib\libwxexpat-2.6.a D:\bin\wxWidgets-2.6.3\lib\libwxjpeg-2.6.a D:\bin\wxWidgets-2.6.3\lib\libwxpng-2.6.a D:\bin\wxWidgets-2.6.3\lib\libwxregexu-2.6.a D:\bin\wxWidgets-2.6.3\lib\libwxtiff-2.6.a  -mwindows
Info: resolving wxStringBase::npos       by linking to __imp___ZN12wxStringBase4nposE (auto-import)
Info: resolving wxAppConsole::ms_appInstance        by linking to __imp___ZN12wxAppConsole14ms_appInstanceE (auto-import)
Info: resolving wxFrame::sm_eventTable       by linking to __imp___ZN7wxFrame13sm_eventTableE (auto-import)
Info: resolving _wxFrameNameStr by linking to __imp__wxFrameNameStr (auto-import)
...

then:

Checking for existence: D:\Work\Commercial\test\wxwidgets_static.exe
Executing: "D:\Work\Commercial\test\wxwidgets_static.exe"  (in D:\Work\Commercial\test\.)
Process terminated with status 128 (0 minutes, 14 seconds)
 
which dies horribly with the message:

"The application failed to initialize properly (0xc0000005).  Click OK to terminate the application."

This is a seems like a very promising platform, but looking back it seems the I have been pissing away time on this for at *least* 6 mo, usually for 2-3 days/mo until I get so frustrated that I have to go on to other things.  I am either too dense to float or some real attention needs to be given to default setups, binary distributions and other issues that keep this from being a more popular solution.

Please understand, I do realize and appreciate the amount of effort that goes into a project like this.  Most of it is *so* good, that It is maddening when I cannot use it.

Dave Witten

[Michael]

Hello,

If I were you, I would:

1) Update and re-build wxWidgets with Patch 2 if you are still using a version with Patch 1.
2) Update C::B to the latest revision (nightly build or build by yourself).
3) Instead of using a template, try to generate a new project and set coorectly the include and lib directory (also set correctly the type of application you are developing, e.g., dll).

Best wishes,
Michael

PS.: Search also in the forum. I am quite sure that you will find some useful info.

[wittend]

Hello,

If I were you, I would:

1) Update and re-build wxWidgets with Patch 2 if you are still using a version with Patch 1.
2) Update C::B to the latest revision (nightly build or build by yourself).
3) Instead of using a template, try to generate a new project and set coorectly the include and lib directory (also set correctly the type of application you are developing, e.g., dll).

Best wishes,
Michael

PS.: Search also in the forum. I am quite sure that you will find some useful info.

Will do...  I see that the version on my main system is older that the one I worked with on another machine yesterday.  Aside from my venting, though, there seems to be more than the usual margin for error.  When you set out to set this up for the first time, A person who simply needs to get some work done has difficulty identifying the correct path to follow.

-- Dave

[mandrav]

Try a recent nightly build (today's or yesterday's). One of the changes is the re-designed new project wizard which makes it so much easier to create a *valid* (i.e. with all the correct settings) wxWidgets app.

[wittend]

Try a recent nightly build (today's or yesterday's). One of the changes is the re-designed new project wizard which makes it so much easier to create a *valid* (i.e. with all the correct settings) wxWidgets app.

Thanks.

I also had no Idea that there was a patch 2 available for wxWidgets.

Yes, its getting the settings right that is the key.  I see *so* many messages from people struggling with this. Which should be global, which project specific, which include folders will automatically end up with subolders appended by the build process, and why above all things does wxWidgets bury the critical setup.h include in a folder under lib?? 

I am glad that active development is proceeding so vigorously, but when a project is marked release candidate 2 shouldn't the project be feature-complete and all but the most subtle bugs have been squashed?

[wittend]

Hello,

If I were you, I would:

1) Update and re-build wxWidgets with Patch 2 if you are still using a version with Patch 1.

I did this...

2) Update C::B to the latest revision (nightly build or build by yourself).

Did this...

3) Instead of using a template, try to generate a new project and set coorectly the include and lib directory (also set correctly the type of application you are developing, e.g., dll).

But this last is pretty unclear to me.  Generate using a template?  Write a project from scratch, using some other editor?  And use what as a guide to specifying the 'correct' include and lib directories?  All I have is settings that I *know* don't work, and I have a *lot* of them to choose from.  I will do my best to do something like this, but for now I have lost another workday on this project.

Best wishes,
Michael

PS.: Search also in the forum. I am quite sure that you will find some useful info.

Did that too - lots of lost souls out there...

So here is what my ultra trivial code says now when I build it.  In fact, the build doesn't report an error, It just acan't find an executable to run.

-- Dave

-------------- Build: default in test ---------------
mingw32-g++.exe -LD:\bin\wxWidgets-2.6.3\lib\gcc_dll -LD:\bin\wxWidgets-2.6.3\lib -LD:\bin\CodeBlocks\lib -LD:\bin\wxWidgets-2.6.3\lib  -o TEST.exe .objs\main.o    D:\bin\wxWidgets-2.6.3\lib\libwx_mswu-2.6.dll.a  -mwindows
Info: resolving wxStringBase::npos       by linking to __imp___ZN12wxStringBase4nposE (auto-import)
Info: resolving wxAppConsole::ms_appInstance        by linking to __imp___ZN12wxAppConsole14ms_appInstanceE (auto-import)
Info: resolving wxFrame::sm_eventTable       by linking to __imp___ZN7wxFrame13sm_eventTableE (auto-import)
Info: resolving _wxFrameNameStr by linking to __imp__wxFrameNameStr (auto-import)
Info: resolving _wxDefaultSize by linking to __imp__wxDefaultSize (auto-import)
Info: resolving _wxDefaultPosition by linking to __imp__wxDefaultPosition (auto-import)
Info: resolving _wxStatusLineNameStr by linking to __imp__wxStatusLineNameStr (auto-import)
Info: resolving vtable for wxMenuby linking to __imp___ZTV6wxMenu (auto-import)
Info: resolving vtable for wxMenuBaseby linking to __imp___ZTV10wxMenuBase (auto-import)
Info: resolving vtable for wxListBaseby linking to __imp___ZTV10wxListBase (auto-import)
Info: resolving vtable for wxObjectby linking to __imp___ZTV8wxObject (auto-import)
Info: resolving _wxEmptyString by linking to __imp__wxEmptyString (auto-import)
Info: resolving vtable for wxFrameby linking to __imp___ZTV7wxFrame (auto-import)
Info: resolving _wxEVT_COMMAND_MENU_SELECTED by linking to __imp__wxEVT_COMMAND_MENU_SELECTED (auto-import)
Info: resolving _wxEVT_NULL by linking to __imp__wxEVT_NULL (auto-import)
Info: resolving wxAppConsole::ms_appInitFn        by linking to __imp___ZN12wxAppConsole12ms_appInitFnE (auto-import)
Info: resolving vtable for wxwxMenuItemListNodeby linking to __imp___ZTV20wxwxMenuItemListNode (auto-import)
Info: resolving _wxTopLevelWindows by linking to __imp__wxTopLevelWindows (auto-import)
.objs\main.o:main.cpp:(.text$_ZN6wxMenuC1ERK8wxStringl[wxMenu::wxMenu(wxString const&, long)]+0x5a): variable 'vtable for wxMenu' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN10wxMenuBaseC2ERK8wxStringl[wxMenuBase::wxMenuBase(wxString const&, long)]+0x4c): variable 'vtable for wxMenuBase' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN10wxListBaseC2E9wxKeyType[wxListBase::wxListBase(wxKeyType)]+0x45): variable 'vtable for wxListBase' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN8wxObjectD2Ev[wxObject::~wxObject()]+0xb): variable 'vtable for wxObject' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN8wxObjectC2Ev[wxObject::wxObject()]+0x8): variable 'vtable for wxObject' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN7wxFrameC2EP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_[wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&)]+0x4c): variable 'vtable for wxFrame' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN20wxwxMenuItemListNodeC1EP10wxListBasePS_S2_P10wxMenuItemRK9wxListKey[wxwxMenuItemListNode::wxwxMenuItemListNode(wxListBase*, wxwxMenuItemListNode*, wxwxMenuItemListNode*, wxMenuItem*, wxListKey const&)]+0x39): variable 'vtable for wxwxMenuItemListNode' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x138): undefined reference to `wxWindow::RegisterHotKey(int, int, int)'
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x13c): undefined reference to `wxWindow::UnregisterHotKey(int)'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
 

[Ceniza]

Could you check if you have in the list of defines for your project WXUSINGDLL?

If it's not there add it and rebuild your project.

[Michael]

3) Instead of using a template, try to generate a new project and set coorectly the include and lib directory (also set correctly the type of application you are developing, e.g., dll).

But this last is pretty unclear to me.  Generate using a template?  Write a project from scratch, using some other editor?  And use what as a guide to specifying the 'correct' include and lib directories?  All I have is settings that I *know* don't work, and I have a *lot* of them to choose from.  I will do my best to do something like this, but for now I have lost another workday on this project.

Sorry to not have been very clear. I just meant to create an empty project and then add the include and libs directories, the libraries and whatever you need instead of using a template.

So here is what my ultra trivial code says now when I build it.  In fact, the build doesn't report an error, It just acan't find an executable to run.

-------------- Build: default in test ---------------
mingw32-g++.exe -LD:\bin\wxWidgets-2.6.3\lib\gcc_dll -LD:\bin\wxWidgets-2.6.3\lib -LD:\bin\CodeBlocks\lib -LD:\bin\wxWidgets-2.6.3\lib  -o TEST.exe .objs\main.o    D:\bin\wxWidgets-2.6.3\lib\libwx_mswu-2.6.dll.a  -mwindows
Info: resolving wxStringBase::npos       by linking to __imp___ZN12wxStringBase4nposE (auto-import)
Info: resolving wxAppConsole::ms_appInstance        by linking to __imp___ZN12wxAppConsole14ms_appInstanceE (auto-import)
Info: resolving wxFrame::sm_eventTable       by linking to __imp___ZN7wxFrame13sm_eventTableE (auto-import)
Info: resolving _wxFrameNameStr by linking to __imp__wxFrameNameStr (auto-import)
Info: resolving _wxDefaultSize by linking to __imp__wxDefaultSize (auto-import)
Info: resolving _wxDefaultPosition by linking to __imp__wxDefaultPosition (auto-import)
Info: resolving _wxStatusLineNameStr by linking to __imp__wxStatusLineNameStr (auto-import)
Info: resolving vtable for wxMenuby linking to __imp___ZTV6wxMenu (auto-import)
Info: resolving vtable for wxMenuBaseby linking to __imp___ZTV10wxMenuBase (auto-import)
Info: resolving vtable for wxListBaseby linking to __imp___ZTV10wxListBase (auto-import)
Info: resolving vtable for wxObjectby linking to __imp___ZTV8wxObject (auto-import)
Info: resolving _wxEmptyString by linking to __imp__wxEmptyString (auto-import)
Info: resolving vtable for wxFrameby linking to __imp___ZTV7wxFrame (auto-import)
Info: resolving _wxEVT_COMMAND_MENU_SELECTED by linking to __imp__wxEVT_COMMAND_MENU_SELECTED (auto-import)
Info: resolving _wxEVT_NULL by linking to __imp__wxEVT_NULL (auto-import)
Info: resolving wxAppConsole::ms_appInitFn        by linking to __imp___ZN12wxAppConsole12ms_appInitFnE (auto-import)
Info: resolving vtable for wxwxMenuItemListNodeby linking to __imp___ZTV20wxwxMenuItemListNode (auto-import)
Info: resolving _wxTopLevelWindows by linking to __imp__wxTopLevelWindows (auto-import)
.objs\main.o:main.cpp:(.text$_ZN6wxMenuC1ERK8wxStringl[wxMenu::wxMenu(wxString const&, long)]+0x5a): variable 'vtable for wxMenu' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN10wxMenuBaseC2ERK8wxStringl[wxMenuBase::wxMenuBase(wxString const&, long)]+0x4c): variable 'vtable for wxMenuBase' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN10wxListBaseC2E9wxKeyType[wxListBase::wxListBase(wxKeyType)]+0x45): variable 'vtable for wxListBase' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN8wxObjectD2Ev[wxObject::~wxObject()]+0xb): variable 'vtable for wxObject' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN8wxObjectC2Ev[wxObject::wxObject()]+0x8): variable 'vtable for wxObject' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN7wxFrameC2EP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_[wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long, wxString const&)]+0x4c): variable 'vtable for wxFrame' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.text$_ZN20wxwxMenuItemListNodeC1EP10wxListBasePS_S2_P10wxMenuItemRK9wxListKey[wxwxMenuItemListNode::wxwxMenuItemListNode(wxListBase*, wxwxMenuItemListNode*, wxwxMenuItemListNode*, wxMenuItem*, wxListKey const&)]+0x39): variable 'vtable for wxwxMenuItemListNode' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x138): undefined reference to `wxWindow::RegisterHotKey(int, int, int)'
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x13c): undefined reference to `wxWindow::UnregisterHotKey(int)'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

I have given a try to the wxWidgets template (Windows XP SP2, rev2689 built with GCC 3.4.5, wxWidgets 2.6.3 Patch 2 built with GCC 4.0.3, GCC 3.4.5) and it works fine. It builds without errors and warning and runs fine.

May be the problems you have are not with C::B or the template, but e.g., with your wxWidgets or others.

Patch 2 for wxWidgets 2.6.3 can be found here.

Best wishes,
Michael

[thomas]

Here comes the wxWidgets hater.
Ok, everybody who has read more than 3 threads on this forum knows my opinion on wxWidgets, but seriously: here is a little of my experience.

One important thing with wxWidgets is that you have to build it monolithic (either static or shared, doesn't matter), or your life will be a very unhappy one.
In fact, a monolithic shared build works very nicely out of the box if you can live with distributing a huge dll. If only this dll wasn't so massively fat.

Don't tune any of the configuration options that are readily available because wxWidgets is not really meant to be tuned.
For example, many options that say "can safely be turned off if you don't need it" cause either your wxWidgets build to fail after running 75% OK, or they cause missing symbols when you try to link your program (no error earlier).

Similar strange things happen with non-monolithic builds. In theory, you should be able to leave out a few libraries if you don't use most features, but in practice, it only works if you include almost all or all of them, even for the most basic applications.
Also, I had it happen that the same program linked with a non-monolithic build crashed, but it would work fine with a monolithic build (identical options, except for this one flag).

wxWidgets requires you to link to a ton of other libraries. If you get a thousand errors when building your programs, you should try adding libkernel32.a, libuser32.a, libgdi32.a, libcomdlg32.a, libuuid.a, libole32.a,  liboleaut32.a, libvomctl32.a, libshell32.a, libadvapi32.a.
If you still get missing symbols after that, you may have to add libwinmm.a, libwisock32.a and libwinspool.a too. Unluckily, the project wizard doesn't do that for you.

Last week, I wanted to make a simple statically linked application that did nothing but display a tray icon and two really simple dialogs. Since I did not know the Windows API for displaying tray icons, I made the massive mistake to give wxWidgets a try (as there is a ready-made tray icon class). Bad mistake!
After recompiling wxWidgets in several configurations several times and fighting for four hours to finally get a working 2 MB stripped executable, I decided to use raw Win32 API instead. It took little over one hour including reading the MSDN documentation, and the executable is 17 kB, including icons...

Regarding the project wizard, when I last used it a week ago, it made me cry because it was setting up everything incorrectly (did not specify the correct include and linker paths, and did not configure properly for static linkage either).
However, as Yiannis said above, the wizard has seen an overhaul, so that problem should be solved now. You still may have to add a few libraries by hand, but it should work rather painlessly now.

[wittend]

I have given a try to the wxWidgets template (Windows XP SP2, rev2689 built with GCC 3.4.5, wxWidgets 2.6.3 Patch 2 built with GCC 4.0.3, GCC 3.4.5) and it works fine. It builds without errors and warning and runs fine.

May be the problems you have are not with C::B or the template, but e.g., with your wxWidgets or others.

Patch 2 for wxWidgets 2.6.3 can be found here.

I rebuilt wxWidgets and upgraded the IDE before running this build.  The only thing that I have not yet done is create another app de novo.

-- Dave

[wittend]

Could you check if you have in the list of defines for your project WXUSINGDLL?

If it's not there add it and rebuild your project.

That helped.  I remember explicitly removing WXUSINGDLL because elswhere I had attempted to specify a static build.   

After making this change, the output I recieve is this:

-------------- Build: default in test ---------------
mingw32-g++.exe -pipe -mthreads -Winvalid-pch -include "wx_pch.h" -D__GNUWIN32__ -D__WXMSW__ -DUSE_PCH -D__GNUWIN32__ -D__WXMSW__ -DUSE_PCH -DHAVE_W32API_H -DwxUSE_UNICODE -DwxUSE_THREADS -DWXUSINGDLL  -ID:\bin\wxWidgets-2.6.3\include -ID:\bin\wxWidgets-2.6.3\lib\gcc_dll\msw -ID:\bin\wxWidgets-2.6.3\contrib\include -ID:\bin\CodeBlocks\include -ID:\bin\wxWidgets-2.6.3\include -ID:\bin\wxWidgets-2.6.3\include\wx -ID:\bin\wxWidgets-2.6.3\lib\gcc_dll\mswu  -c wx_pch.h -o wx_pch.h.gch\default_wx_pch.h.gch
mingw32-g++.exe -pipe -mthreads -Winvalid-pch -include "wx_pch.h" -D__GNUWIN32__ -D__WXMSW__ -DUSE_PCH -D__GNUWIN32__ -D__WXMSW__ -DUSE_PCH -DHAVE_W32API_H -DwxUSE_UNICODE -DwxUSE_THREADS -DWXUSINGDLL  -ID:\bin\wxWidgets-2.6.3\include -ID:\bin\wxWidgets-2.6.3\lib\gcc_dll\msw -ID:\bin\wxWidgets-2.6.3\contrib\include -ID:\bin\CodeBlocks\include -ID:\bin\wxWidgets-2.6.3\include -ID:\bin\wxWidgets-2.6.3\include\wx -ID:\bin\wxWidgets-2.6.3\lib\gcc_dll\mswu  -c main.cpp -o .objs\main.o
mingw32-g++.exe -LD:\bin\wxWidgets-2.6.3\lib\gcc_dll -LD:\bin\wxWidgets-2.6.3\lib -LD:\bin\CodeBlocks\lib -LD:\bin\wxWidgets-2.6.3\lib  -o TEST.exe .objs\main.o    D:\bin\wxWidgets-2.6.3\lib\libwx_mswu-2.6.dll.a  -mwindows
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x138): undefined reference to `wxWindow::RegisterHotKey(int, int, int)'
.objs\main.o:main.cpp:(.rdata$_ZTV7MyFrame[vtable for MyFrame]+0x13c): undefined reference to `wxWindow::UnregisterHotKey(int)'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 8 seconds)
0 errors, 0 warnings

I believe that I may be down to only the Hotkey errors.  I quess that those calls relate to the the default menu items in the minimal application.  If only I knew how to get rid of them.

-- Dave

[wittend]

Aha! I built a new minimalist app with the new Wizard, and it worked! 

Thanks to everyone who read my posts and offered their suggestions!

-- Dave

[Michael]

Here comes the wxWidgets hater.
Ok, everybody who has read more than 3 threads on this forum knows my opinion on wxWidgets, but seriously: here is a little of my experience.

Hello,

Thank you very much for this very interesting post .

Best wishes,
Michael

[troels]

I wanted to make a simple statically linked application that did nothing but display a tray icon and two really simple dialogs. Since I did not know the Windows API for displaying tray icons, I made the massive mistake to give wxWidgets a try (as there is a ready-made tray icon class). Bad mistake!

:shock:
wxTaskBarIcon works fine for me. I don't remember having any initial problems, it did what I expected it to do.
/wx/samples/taskbar/vc_msw/taskbar.exe is 860 KB on my system:
MSVC6, wx 2.6.3.2 optimized for size using *statically* linked C runtime
The MS linkers excels at tossing out unused code.

[thomas]

wxTaskBarIcon works fine for me. I don't remember having any initial problems, it did what I expected it to do.
/wx/samples/taskbar/vc_msw/taskbar.exe is 860 KB on my system

I did not say it does not work in general. It does work, in fact it works inside Code::Blocks, too (batch builds).

It is a well-known fact that gcc bloats wxWidgets executables even more than MSVC (2 MB executable in my case), but that's not the point. My point is that you can try for many hours to get down to a reasonable size, and it is just hopeless. Similar figures apply to the memory footprint.

You will certainly agree that >800 kB is outright ridiculous ( >2 MB even more so) for an application that shows an icon and two simple dialogs and does not do an awful lot of magic. I would not mind if it was 50 or 60 kB, maybe even 80, but certainly not 800.

It should really be possible to get something of a reasonable size by statically linking only what you really need and by disabling features that you definitely never use, but in my experience, all you get is a broken build.

[troels]

You will certainly agree that >800 kB is outright ridiculous

Absolutely not, I disagree.
860 KB seems like an ok price to pay for having a x-platform gui framework to hold your hand.
(Unless you happen to hate the framework)
This is bloat:
email clients

[thomas]

This is bloat: http://img90.imageshack.us/my.php?image=bloat4fj.png

860 KB seems like an ok price to pay for having a x-platform gui framework to hold your hand.

It is an OK price if you write a program that's 10-15 MB in size anyway (for example Thunderbird, which you call "bloated"). However, it should be possible to get away with a few dozen kilobytes otherwise. Also, it is not only about file size, but about memory, too.

The "Hello World" application that you can build using the wx template has a virtual size of 39760 kB and a working set of 5876 kB. Just like the file size, this memory footprint is absolutely ridiculous for a program that does nothing but show a naked window and an about box.

If you are sitting on your development machine with 2 GB of physical RAM, then you can relax, lean back and say "yeah, yeah, shut up, so what".

However, if your tool is to be used by a few hundred people who are to have it running 8 hours every day on typical backoffice machines that have 256 MB (maybe 512 MB if you're lucky) and on which they have to use Outlook, Word, Excel, and Lotus Notes at the same time (and a couple of smaller apps), then a puny few megabytes of RAM that are gone for no obvious reason do matter a lot.
The same goes for loading an unnecessarily big program off the network share in the morning.

[BordRider]

In troel's defense, I think he meant that Outlook is bloated, it's more than 20 times the size of Thunderbird and they are meant for the same purpose (although Outlook does have more features, it farms some tasks out to other office programs, like Word for email editing, which is definitely bloat).

But you're right, and this is off topic, so I'll stop.

[troels]

In troel's defense, I think he meant that Outlook is bloated, it's more than 20 times the size of Thunderbird

Certainly. Thunderbird is cool (small footprint).
The calendar functionality of Outlook comes at the price of 300 extra megabytes

[troels]

Speaking of code bloat, CB is really giving it to Eclipse, here:

EasyEclipse for C and C++ vs Code::Blocks

EasyEclipse: not easy on memory!

 

Edit: Where did my avatar go?
Did it get censored?  :?

[mandrav]

Edit: Where did my avatar go?
Did it get censored?  :?

Uhm, no. This morning the attachments folder was cleaned up from old content. In your case, old content meant "avatars of members not visited the last 45 days". Sorry for the confusion. I guess it would be easy for you to re-upload it?

[troels]

I guess it would be easy for you to re-upload it?

Absolutely. Just checking the waters
/Troels