Check out the wxWindowsQuickRef (http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef).
Thank you for the very interesting link, which I had previously missed.
At a first glance, however, it seems that until now I've followed the correct procedure, at least for what concerns the "Build wxWidgets" section.
I have just a curiosity: why do you consider the "MONOLITHIC=1" option to be better?
Please give the exact command used and someone should be able to help you.
The options needed to be picked in the wizard must be the correct ones as determined by the ones used by mingw32-make options.
Tim S
The exact command was the one I've written above: from inside the '<wxWidgets>\build\msw ' directory (to use the same name convention adopted in the tutorial linked above)
mingw32-make -f makefile.gcc BUILD=release
with the 'SHARED=1' and 'UNICODE=1' assigned by modifying the 'config.gcc' file instead of giving it as an option in the command line (which could easily be the reason for all the hassle). And in fact, the compilation process ends well, and the libraries seem to be all there, where they're supposed to be.
Or at least, this is what I think: for I admit I'd actually find very useful to have, in the wxWidgets' README or HOWTO-INSTALL, sort of a recapitulation of how a well-built distribution should look like. I mean, something like the "summary of what you should have inside your release, once you've unzipped it to where you like" recommendation that the developers of MinGW put in their releases...
Anyway, as soon as possible I'm going to make other experiments. I'll post the results here (but only if they'll be positive ;D )
As promised, here are a couple of impressions after two more days of "ruminations on C::B + wxWidgets".
So: wxMSW installed by simply unzipping the archives in a suitable directory, rather than using the 'setup.exe' (for, in case things wouldn't work, I can simply trash everything, instead of having to go through the control panel way).
Then, compiled, following the recommendations of the WxWindowsQuickRef (http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef), except for the fact that I choose not to build a monolithic DLL, and I opt for the multiple components way. All and all, I believe this to be a better solution, at least for my specific needs (which, right now, are those proper of/related to a setup which is quite "experimental"). Thus, my command line runs as follows:
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=0 UNICODE=1
After some twenty minutes, and a long series of 'Warning: type attributes are honored only at type definition' (which, following the aforementioned tutorial, I happily disregard ;^D ), MinGW-GCC triumphantly communicates to me that the cake is baked, and it should be nice.
And it's good, indeed. In fact, the sample programs in the 'samples' subdirectory compile with absolutely no trouble, obviously provided I build them with the same command line I've used to build the libraries.
Let's test it with Code::Block, then. So I open it, I call the wizard, I select all the appropriate options, paying a particular care to mimicking exactly the ones I've selected in the libraries' building process before (that is: Use wxWidgets DLL [X] / wxWidgets is built as a monolithic library [ ] / Enable unicode [X]), and, let's go, the wxSmith window opens and I find myself in front of a frame, into which something is intended to be placed.
Nonetheless, I do absolutely nothing, here. It's just a test, and I simply want to see the whole engine at work. So I save everything, I start building, and... surprise!! nothing works, and MinGW-GCC repeatedly complains about the following:
-------------- Build: Debug in wxTest1 ---------------
Compiling: wxTest1App.cpp
Compiling: wxTest1Main.cpp
Compiling: resource.rc
Linking executable: bin\Debug\wxTest1.exe
obj\Debug\wxTest1App.o: In function `ZN12wxAppConsole16OnFatalExceptionEv':
C:/Programs/A_Engines/Development/wxMSW/include/wx/app.h:(.rdata$_ZTV10wxTest1App[vtable for wxTest1App]+0x90): undefined reference to `wxAppConsole::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*)'
C:/Programs/A_Engines/Development/wxMSW/include/wx/app.h:(.rdata$_ZTV10wxTest1App[vtable for wxTest1App]+0x94): undefined reference to `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)'
obj\Debug\wxTest1Main.o: In function `ZNK12wxWindowBase10GetMinSizeEv':
C:/Programs/A_Engines/Development/wxMSW/include/wx/window.h:(.text$_ZN12wxStringBaseC2ERKS_[wxStringBase::wxStringBase(wxStringBase const&)]+0x47): undefined reference to `_imp___Z10wxOnAssertPKwiPKcS0_S0_'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 10 seconds)
3 errors, 0 warnings
After two days of pointless efforts, during which I repeatedly try to remake everything from scratch, while at the same time varying the build flags and parameters, and the libraries to be linked and those not to be linked, and the like, in every possible way, finally I have an idea. Is it possible that, every time the wizard tells me that it can't find, in the wxMSW root, a debug configuration of libraries (since I, following the WxWindowsQuickRef (http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef), was choosing every time to work in debug mode, notwithstanding the fact that I had built the libraries in release mode) consistent with the choices made in its previous stages, it is right?
So, in my n-th attempt, I finally decide to open a release mode project. As a first thing, the wizard doesn't complain, at last, about the congruency between the libraries' distribution and what I'm trying to make, which looks like a promising start.
Then, everything goes as before, I save what the wizard presents to me without changing a comma, start the build, and... voilĂ , finally, just before I was beginning to think I'd rather go look for a gun and shoot myself, the so highly desired message: Process terminated with status 0 (0 minutes, x seconds) / 0 errors, 0 warnings.
Everything considered, then, here is my opinion: it seems to me that it is not correct to suggest you can build the libraries in a 'BUILD=release' mode, and then in C::B's wizard do whatever you like, because the wizard doesn't recognize any other build mode than the one you previously gave to the compiler, and there's no way at all of avoiding this in the following.
So, if you plan to build wx projects in debug mode, you have to know clearly and in advance that you must build the wx libraries IN DEBUG MODE. In this case, however, I suspect that the wizard wouldn't allow you to create any RELEASE project whatsoever, no matter what you do, and would constrain you exclusively to the DEBUG mode.
Am I wrong?