Author Topic: Compiling a wxWidgets application - wx/setup.h: No such file or directory  (Read 63589 times)

svaens

  • Guest
Hi all,

First, I realise that someone has posted a similar topic with similar subject title. However, It did not seem to come to conclusions that helped me out much. And the topic was very old, and rather than reply to that, i started a new topic. Hope that is ok.

I am a newcomer to codeblocks, and also a newbie at wxWidgets. I'll briefly outline what I HAVE achieved, and where I am stuck.

1. Installed code::blocks, and tested by compiling first a windows console app, and then a standard win32 gui. (ALL GOOD)

2. Installed and built wxWidgets using MinGW and MSYS. Build went perfect, and was able to test make 'making' a sample project from command line. (ALL GOOD)
Sample = samples\minimal
Documentation I followed in building wxWidgets:
http://www.wxwidgets.org/wiki/index.php/Compiling_WxWidgets_With_MSYS-MinGW

3. Try building a sample wxWidgets application for first time using code::blocks
i.e. (New Project->wxWidgets Project->wxWidgets 2.8.x
(PROBLEMS!!)

I enter the path of my wxwidgets build, and specify seperately the path of the include, lib, and obj files. eg
(#wx.include)
(#wx.msw-debug.lib)
(#wx.msw-debug)
where the Base is the path of my wxWidgets build, at C:\dev\wxWidgets-2.8.4,
AND i had built it as instructed in a child directory, msw-debug

First problem I encounter is from the wizard screen that starts with "Please select various configuration options."
After clicking next, i see the Warning message box saying "A matching Debug configuration cannot be found in the wxWidgets directory you specified...."
It says this for both Debug target and Release target.

At this stage I figure that this means for some reason it can't find my lib files. And i decide i will try and fix this later in the project options. So I continue.

I select all additional wxwidget libraries to add to the project. And Finish.

On building a file, I get the following compile errors

Compiling: testwxApp.cpp
In file included from C:/dev/wxWidgets-2.8.4/include/wx/defs.h:21,
                 from C:/dev/wxWidgets-2.8.4/include/wx/event.h:15,
                 from C:/dev/wxWidgets-2.8.4/include/wx/app.h:20,
                 from C:\Temp\TestProject\testwx\/testwxApp.h:13,
                 from C:\Temp\TestProject\testwx\testwxApp.cpp:18:
C:/dev/wxWidgets-2.8.4/include/wx/platform.h:196:22: wx/setup.h: No such file or directory

C:/dev/wxWidgets-2.8.4/include/wx/chkconf.h:98:9: #error "wxUSE_DYNLIB_CLASS must be defined."
C:/dev/wxWidgets-2.8.4/include/wx/chkconf.h:106:9: #error "wxUSE_EXCEPTIONS must be defined."
C:/dev/wxWidgets-2.8.4/include/wx/chkconf.h:114:9: #error "wxUSE_FILESYSTEM must be defined."

etc, etc

So, it seems that there is a wx/setup.h in the lib path ?? This is strange. Anyway. This is probably my problem.... But I can't find where I should add this path (for additional includes) so that it can find it.
Also, why was I receiving those Warnings at the construction of the project. Is it because I built my wxWidgets to $base/msw-debug instead of directly in the wxWidgets base folder?? If so, surely there is a way to setup the project to handle this.

Please Help!!!!!

Thanks and Kind Regards,

svaens


Offline dje

  • Lives here!
  • ****
  • Posts: 683
Hi !

As far as I remember, when you build wxWidgets, a setup.h is generated in a lib subdirectory.
You have to put it in the include paths too.

Dje

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
C::B's wxWidgets wizard does not support MSYS-MinGW compiled wxWidgets lib. On Windows, please compile wxWidgets from command prompt which wizard can detect and configure.
Be a part of the solution, not a part of the problem.

Offline thatgui

  • Single posting newcomer
  • *
  • Posts: 4
got the same problem. djes tip did the trick -> maybe this could be added to the wiki ?

Offline ggpr

  • Multiple posting newcomer
  • *
  • Posts: 13
I also think theres a setup0.h hidden in the directorys somewhere that can be placed where it needs to be

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
I also think theres a setup0.h hidden in the directorys somewhere that can be placed where it needs to be

The problem is normally the user did not use mingw32-make or some other make to compile wxWidgets.
Copying the setup0.h does not fix the problem!!

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline schroeder

  • Single posting newcomer
  • *
  • Posts: 8
...so.... how does this story end? ;)

[I ask this because I've got stuck exactly in the same problems svaens has encountered... so I'd like very much to know if this story ends well :)]



P.S.:
C::B's wxWidgets wizard does not support MSYS-MinGW compiled wxWidgets lib. On Windows, please compile wxWidgets from command prompt which wizard can detect and configure.

I'm sorry but it's not my case. Setup:
  • MinGW 3.4.5 installed in a directory with no spaces in the path (this, just to exclude the possibility that the issues amount to "something" - whatever it can be, a compiler, a linker, etc. - unable to find "something else") and, in fact, currently working, for instance, just with CodeBlock in the "console" mode
  • wxWidgets 2.8.7 installed and compiled with the utmost care (that is, following exactly the instructions they put on the official README/INSTALL), both in the "pure MinGW" mode (that is, with 'mingw32-make -f makefile.gcc BUILD=debug(release)') and in the "MSYS" mode (=>./configure - make)

Notwithstanding this, in both cases things run as told by svaens. The wizard doesn't recognize the installation completely, and the compile process halts. I've been wondering why for the last two days, without being able to get to any solution ^^

BTW, svaens: the "wx/setup.h: No such file or directory" issue is quickly fixed by simply copying the 'setup.h' file, which by default is laid aside unhelpfully in a subdirectory of the '\build\msw\the-name-you-choose-for-this' dir where you actually built the compiler-specific release, to the '\include' directory, where it's actually needed.

Unfortunately, however, this only makes the compiler stop complaining about not finding the header where it should be: but it doesn't fix the other problems ^__^
« Last Edit: March 16, 2008, 08:28:07 pm by schroeder »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
mingw32-make -f makefile.gcc BUILD=debug

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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Check out the wxWindowsQuickRef.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline schroeder

  • Single posting newcomer
  • *
  • Posts: 8
Check out the 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)

Code
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 )

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
I have just a curiosity: why do you consider the "MONOLITHIC=1" option to be better?
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.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline schroeder

  • Single posting newcomer
  • *
  • Posts: 8
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

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

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?
« Last Edit: March 26, 2008, 05:49:58 pm by schroeder »

Offline dje

  • Lives here!
  • ****
  • Posts: 683
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

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
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?
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.
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.

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.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline schroeder

  • Single posting newcomer
  • *
  • Posts: 8

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.
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.

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.

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....