User forums > Using Code::Blocks
Compiling a wxWidgets application - wx/setup.h: No such file or directory
TDragon:
--- Quote from: schroeder on March 17, 2008, 09:24:40 am ---I have just a curiosity: why do you consider the "MONOLITHIC=1" option to be better?
--- End quote ---
This makes the development process of a program easier -- you don't have to worry about adding the appropriate libraries when you bring in a previously unused portion of wxWidgets, and you don't have to worry about distributing multiple wxWidgets DLLs. One import library, one DLL. It's been my experience (and obviously the C::B developers' as well) that the slight overhead in size is worth the decreased hassle.
schroeder:
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, 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:
--- Code: ---mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=0 UNICODE=1
--- End code ---
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:
--- Code: ----------------- 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
--- End code ---
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, 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?
dje:
Hi !
I don't know if you're wrong.
I work on a wxwidgets application with C::B both in release and debug mode and all works OK.
I didn't use the wizard to create my project.
I play only with monolithic debug and release dlls.
Dje
TDragon:
--- Quote from: schroeder on March 26, 2008, 05:29:03 pm ---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.
...
Am I wrong?
--- End quote ---
Yes. I believe all your debug build troubles have stemmed from a bug in the wxWidgets project wizard (and therefore in the wxWindowsQuickRef instructions). Currently, in the wxWidgets project wizard, you must check the Configure Advanced Options box in order for your preference of using a release or a debug build of wxWidgets in the debug target to take effect. In other words, if you don't "Configure Advanced Options", the "Use __WXDEBUG__ and Debug wxWidgets lib" box defaults to checked; if you do Configure Advanced Options, it defaults to unchecked.
Until this bug is fixed, the line in the wxWindowsQuickRef which reads:
--- Quote ---If, for some reason, you want to use a debug wxWidgets build, select "Configure Advanced options" and then select "Use __WXDEBUG__ and Debug wxWidgets lib" on the next page.
--- End quote ---
should be amended to:
--- Quote ---In order to avoid using a debug wxWidgets build (as recommended), you must select "Configure Advanced options" and then leave "Use __WXDEBUG__ and Debug wxWidgets lib" unchecked on the next page.
--- End quote ---
Hope that clears it up a bit. Be assured that it truly is possible (and desirable) to use a release build of wxWidgets with a debug build of your program -- this is what Code::Blocks itself does, as you can see in the C::B project file in its sources.
schroeder:
--- Quote from: TDragon on March 26, 2008, 08:36:05 pm ---
I believe all your debug build troubles have stemmed from a bug in the wxWidgets project wizard (and therefore in the wxWindowsQuickRef instructions). Currently, in the wxWidgets project wizard, you must check the Configure Advanced Options box in order for your preference of using a release or a debug build of wxWidgets in the debug target to take effect. In other words, if you don't "Configure Advanced Options", the "Use __WXDEBUG__ and Debug wxWidgets lib" box defaults to checked; if you do Configure Advanced Options, it defaults to unchecked.
Until this bug is fixed, the line in the wxWindowsQuickRef which reads:
--- Quote ---If, for some reason, you want to use a debug wxWidgets build, select "Configure Advanced options" and then select "Use __WXDEBUG__ and Debug wxWidgets lib" on the next page.
--- End quote ---
should be amended to:
--- Quote ---In order to avoid using a debug wxWidgets build (as recommended), you must select "Configure Advanced options" and then leave "Use __WXDEBUG__ and Debug wxWidgets lib" unchecked on the next page.
--- End quote ---
Hope that clears it up a bit. Be assured that it truly is possible (and desirable) to use a release build of wxWidgets with a debug build of your program -- this is what Code::Blocks itself does, as you can see in the C::B project file in its sources.
--- End quote ---
It surely does, and I thank you again for the accuracy of your replies. Actually, I myself have come to a similar conclusion during these last days, and that's what I was about to write, something like "everything considered, either there's a bug in the whole wxWidgets distribution/building process, which is quite improbable, since so many people use it with absolutely no trouble: or there is a problem somewhere, in the current wxWidgets wizard, that causes all this series of troubles". And I would have written it, hadn't I already made sort of a flood... :^D
Anyway, I believe I've learned something more....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version