Author Topic: wxWidgets don't work  (Read 9343 times)

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
wxWidgets don't work
« on: April 09, 2016, 04:08:22 am »
On WinXP64, CB 16.01 GNU/MinGW-64/GCC 5.3.0

Tried to create a wxSmith/wxWidget's project.  wxWidgets 3.02 was already installed in the usual MingW locations, with the usual (MSys) process. 

CB would NOT accept that location, and would not permit getting past the message

    "The path you entred seems correct, but this wizard can't locate wxWidget's file ..."

I also had  wxWidgets 3.x installed in a completely independent MSys2 install, and had the same experience with that.

Unfortunately, the "message" above was not too helpful, and only after much time did I find (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_2.8.6_to_develop_Code::Blocks_%28MSW%29), where it became clear that a very non-standard install process was required for CB. 

... please update that dialog box/message with a more useful message, and particularly that a non-standard install is required, and possibly point to the instructions page.


However, the instructions on the CB install wxWidgets page may require some updating too.

1) It was not possible to compile wxWidgets 2.x, at least not without much time in "bash hell".

2) Compiling 3.x with the special instructions did work, eventually, to extent of "compiling", but see point 5) below.  A few points to consider including in the instructions (some of which are particular to wxWidgets):

a) If wxWidgets was already installed by any normal means on a previous occasion, it may well have created .PCH files.  The clean option may not remove those, or certain other files, so a make after a clean may not have the desired results.

b) With 3.x, the make requires CXXFLAGS=-std=gnu++11 to be set (notice, it must be CXXFLAGS=-std=gnu++11, and not c++11, due to some wx peculiarity, and yet another item that could waste many hours of one's life).

c)  I think the CB instructions should mention make's -j option, for those on multi-processor/core machines.  It massively speeds up the compile process when set to even a small number > 1.

Ultimately, I used a make command:


mingw32-make -j 3 -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS=-std=gnu++11

with and without "clean".


3) Though the compile "worked", these instructions do NOT install the resultant dll's etc in the expected location (e.g. not in the usual local32/bin etc or equivalent typical MinGW structure).  Rather, all the compilations results end up in the "build" dir ..\wxWidgets-3.0.2\lib\gcc_dll. 

4) The CB instructions speak of running, post compile, a file called update.bat, but I could not find any such file in any location either in the MingW dir structure, or the CodeBlocks dir structure.  As such, I can't be sure if that is the reason for the failure in the next step.


5) Then, even with the dll's in an odd location, re-attempting to start a CB wxWidget project resulted with exactly the same show-stopping dialog box/message that CB could not see the files.


Please advise on how to proceed to be able create wxWidget projects. 

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: wxWidgets don't work
« Reply #1 on: April 09, 2016, 05:47:31 am »
Please advise on how to proceed to be able create wxWidget projects.
You can modify the wizard yourself (right-click on it and select "edit"). Its based on a scripting language that is easy to understand. If you found a way that works for all cases, provide a patch.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #2 on: April 09, 2016, 07:25:31 pm »
OK, so it took a little fiddling, but eventually we figured out what you meant by "wizard" was to right click on wxWidget icon following File->Projects-> ... etc.

Therein, one can see that the CB criteria for accepting the presence of wx is locating the wx.h file in a dir "/include/wx/wx.h".  As illustrated below, there is no chance that would work as it stands.

So, that is easy enough to edit, but edit to what??  In particular:

1) The tradition install of wx puts all the wx compiled/required files into the traditional MinGW locations, which in our case would be ../local32/bin, /local32/lib, etc.  The traditional approach also puts the wx.h file in a dir /local32/include/wx-3.0/wx (noting the extra layer compared to what CB expects).

2) However, the traditional install approach (i.e. using config/make/install with MSys), apparently is NOT permitted, and the special CB make procedure (as per the CB instructions page) must be followed.

With that approach, ALL of the make results are placed inside the BUILD dir, where the wx source etc files reside, and with non traditional dir structures.  For example, the CB strategy places wx.h in

D:\Apps\MingW\build32\wxWidgets-3.0.2\include\wx

and places all the dlls in D:\Apps\MingW\build32\wxWidgets-3.0.2\lib\gcc-dll\, such as the file wxmsw30u_gcc_custom.dll, which we presume is the "monolithic" version  specifically required by CB.


So, now there appears to be three options:

1) Point CB/wx to the files in the Build dir's.  This would seem a very bad idea, since the normal practice is to delete the Build/source dir's after install.  Moreover, then the entire wx kit would exist outside of the MinGW structure/paths/env's etc.


2) Copy the files created with the CB special make procedure to the appropriate dirs in the MingW structure.   Unfortunately, we, being newbies, are not sure which files to copy (we can guess at some of them, but are likely to miss others).  Moreover, for all we know, the CB special procedure also creates ENV settings and such, which may/would continue to look for wx files in the Build dir, after they've been moved to the MingW locations.


3) Is there a special CB procedure that could build/install wx, and install all the files in the traditional MinGW locations automatically.  Normally, we would use something along the lines of

cd [source] && \
./configure -preifx=[dest] ...... && \
make && \
install

though of course that would be all from within an MSys shell, so something from a CMD would be required, presumably.


Please keep in mind we are "math geeks", not "IT geeks", and due to our inexperience with deep IT matters, much of what we accomplish is via a kind of "inspired monkey see, monkey do".  When wrinkles come up, we need some extra clarity wrt the instructions.

Once those "where to put the file" bits are finalised, we will edit the wizard accordingly.

Cheers

DrO

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: wxWidgets don't work
« Reply #3 on: April 09, 2016, 10:20:17 pm »
I took the effort once to get wx-config to work with Code::Blocks and MSys2.
I had to edit the C::B source to get it to work how I think it should; but, it was possible to get an wxWidgets project to work without editing the C::B source.
That method used a Global Var that pointed to the MSys2 installation. For some weird reason the Global Var had issues with the "/" being replaced with "\".
Edit1: I never found the solution to the "/" being replaced with "\"; that is why I am working on a C::B source fix; but, it has turned out to be harder that I thought it would be to finish.
So, you will likely have to edit the Global Variable everytime you start Code::Blocks; but, this work was before 16.01 was released; so, maybe the issue is gone.

If you want I can make up a simple CB wxWidgets project using the Global Variable method, do you want it?
I am guessing you are using the native MSys2 wxWidgets 3.0.2, correct?
If not, I am NOT certain the solution will work.

Note, this would NOT fix the C::B wxWidget's wizard. But, could be used as a CB Template.

I have no idea if I kept my prior work or will be starting from scratch.

Tim S.
« Last Edit: April 09, 2016, 10:24:10 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #4 on: April 10, 2016, 06:55:28 pm »
Cheers for that:

1) We use GlobalVars also, always have.

2) We don't see any "\" vs. "/" issues arising here.


3) We have now tried MANY different approaches, none of which seems workable.  As noted, I had thought of three different possible solutions in my previous post. 

Before I speak to those, I should mention again that we actually have two completely independent MinGW installations:  one is an MSys2 based install, and the other is what we refer to as an "Ingar MinGW", since it built using the steps outlined by "Ingar" here (http://ingar.satgnu.net/devenv/mingw32/index.html). 

The Ingar MingW is our "core" approach to MingW matters.  It is basically a "DIY from scratch" approach.  It is extremely tedious, but it gives us full control over what is installed, and how.  By contrast, with MSys2 you get what ever is in the Repository (e.g. this can be crucial since some of what we do is explicitly GTK2 dependent, and keeping GTK2/GTK3 bits, or any critically version dependent items,  separate in MSys2 is not easy, etc etc).

We have found that if we install wxW 3.02 either in MSys2 or in IngarMingW, we get pretty much the same thing, in pretty much the same "equivalent" places.  So in this respect, purely for wxSmith/CB testing, there appears to be no difference between the two MinGW's.

HOWEVER, neither of those wx installs is compatible with CB's internal requirements as far as we can tell.  Amongst other things:

a) Neither produces a monolithic

b) BOTH have "extra" Dirs, for example, while CB is looking for /include/wx, both MingW's have /include/wx-3/wx instead, see also below.

c) Neither MingW has setup.h etc, which appears to be needed by CB.


4) Using the CB instructions produces a completely different Dir structure compared to any normal MinGW install, e.g. there is not the usual /bin, /include, /lib, etc Dirs.  Moreover, none of the CB specific installed files end up in the MingW structure, but rather produce Dir's with .h's, dll's, etc directly in the "build or source" dir, with an unusual dir structure.  Out tests have made no progress at all with the CB instructions based install.


5) Some experiments:  we tried several different set-ups, with various permutations,

(i) some with MSys2 wx,
(ii) some with IngarMingW wx.
(iii) some with the CB instructions based wx install.
(iv) some with creating a special Dir structure that follows the "normal" /include, /bin, etc etc structure, and copying all the files created by the CB specific installation creation in that weird "in build/source" dir's, to these "normal looking" Dir structures.


a) Attempting to use any of the MingW installs can be "started", by editing the Wizard to test for wx.h in wx-3.0/wx/ ... regardless of whether global vars have been set.

That allows the project to be "started".  However, all throughout the CB internal files, there are things like #include "wx/...".  Every single one of those must be changed "wx-3.0/wx/....".

b) There is not a setup.h in any of the MingW installs.  Even with the CB instructions, the wx dir has a setup_inc.h, while "setup.h" files are in further sub dirs, so all of the CB internal files looking for include "include/setup.h" must also be edited ... though we have idea what that edit should be.


c) Even if we all those edits were performed, which we have NOT (it just started to seem too iffy to us), we can't be sure what CB would would then even see the monolithic dll's.


As a final note, the only experiment where we actually got to the wxSmith screens ... i.e. actually seeing the wx editor, related code, etc, was the test where we edited the wizard, and used the either the MSys2 or IngarMingw's standard wx install (i.e. requiring editing all the CB files as well, and no guarantee that the non-monolithic would work, if we ever got that far).


We have absolutely no idea how to proceed from here, short of re-writing all the CB internal files ... and quite frankly we would wish to avoid that, even if we knew how.

Also, it is our strong preference to work with Ingar MinGW, since there we have absolutely full control over building everything from scratch (as tedious as that may be), whereas MSys2 is restricted to whatever they supply, in whatever form they supply it in ... but will work with MSys2 if that makes it easier for you.


If you have a template for us to test, we would be happy to do ... though we are struggling somewhat. 

Moreover, we are wondering if an alternate version of the CB specific install instructions should be considered, so that it at leasts produces a workable dir structure, even if it is isolated from the normal MingW dir's.  That is, the CB instructions should produce a dir structure etc that is consistent with what CB is expecting, even if it is not usable in any other normal way by other apps etc requiring wx.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2461
Re: wxWidgets don't work
« Reply #5 on: April 10, 2016, 11:28:31 pm »
This is all a lot text and just to make sure i understand everything:
1) You are using Windows XP
2) Your "normal" approach to build wxWidgets is to go with msys and the configure script provided by wxWidgets?
3) To clear things up: as far as i understand the "normal" way to build wxWdigets under windows is the way how it is described in our wiki (see in  install.txt  the point "* Using plain makefiles:"from the wxWidgets documentation. In a "normal" case you won't install all the unix tools in a windwos environment.)
Quote
these instructions do NOT install the resultant dll's etc in the expected location
Under windows i wont expect the libraries to be installed in /lib etc... subdirectories. This is a unix approach...
BUT: this is not the point we are talking about, so i won't discuss this future :) .

4) I don't think that codeblocks "needs" a monolithic build. I have used codeblocks also with non monolithic builds. You simply have to remove the tick at the "wxWidgets is build as a monolithic library" at the 8. Wizard page.


Your problem, as far as i can tell, is: You use the "configure" approach to install wxWidgets under windows and codeblocks does not detect it with its default scripts?

So we need a second search script, that can detect the "configure" approach?

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #6 on: April 11, 2016, 04:58:20 am »
No, that seems to miss crucial points.  As indicated in the previous messages, we have tried MANY MANY permutations.  Roughly speaking they fall into four completely independent efforts.  We have tried these efforts under both WinXP64 and Win7/64, but mostly WinXP64.

As indicated repeatedly, one of those key entirely independent efforts was to use what we keep referring to as the "CB instructions", and which we had carefully cited in our original post as coming from here (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_%28MSW%29).  We understand that to be CB special required install process.

Our previous submissions include some adjustments required to the make the CB instructions work with 3.x (e.g. gnu++11, etc).

The make appeared to work.  However, as repeatedly emphasised, it "makes" the files in a highly unusual directory structure.  We don't know if that is one of the reasons why we can't get it work in CB.

To be clear, once again, this is completely and entirely independent of any of the other efforts we tried via any flavour of MinGW or "config" etc etc.


Using the "CB instructions", when we try to create a wx project, and after some fiddling for the wizard to even accept the (CB specific) wx.h location etc, the wizard allows us to get past the next couple of dialogues, eventually to arrive at something like:


SquirrelFunction<> call failed
AN ERROR HAS OCCURED [arith op + on between 'null' and 'instance']

CALLSTACK
*FUNCTION [OnLeave_WxConf()] D:\Apps\CodeBlocks\share\codeblocks/templates/wizard/wxwidgets/wizard.script line [363]

LOCALS
[lib_rel_name] INSTANCE
[lib_deb_name] INSTANCE
[lib_name] NULL
[lib] INSTANCE
[lib_suffix] NULL
[lib_unic_suffix] INSTANCE
[lib_wxver] INSTANCE
[lib_prefix] NULL
[fwd] true
[this] TABLE


We have no idea what that means, and cant find any way to make progress along those lines.  Though, it would not surprise us to learn that this may mean it can't find the dll's etc, possibly since the "CB Instructions" produce a somewhat unusual dir structure for the "make" results ... and likely we are missing some information.

As for "monolithic", clearly the CB specific instructions from the CB web page cited insist on monolithic.

We were under the impression from previous responses that editing the wizard was the suggested fix.  Based on that, which was in connection with a MinGW install (c.f. a "CB make"), We had said that the only way we could actually get CB to get to a "proper" wx project, where CB actually shows the "drawing area", cpp's, etc was by editing the wizard, and using a MingW installation, though that posed new problems, and we did not expect that work for the reasons already stated previously.


To summarise, we have tried many different entirely independent approaches, initially focusing on the "CB instructions", but later also testing MinGW approaches.

We are happy to help/try any approach (be it "CB make", MSys config, whatever), but again we are "math geeks", not "IT geeks", and we need at least some assistance to move forward, and apparently many crucial bits are in CB's internal machinery/files.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: wxWidgets don't work
« Reply #7 on: April 11, 2016, 10:58:36 pm »
I tried to recreate my past steps and failed using MSys2 GCC 5.3; I am wondering what GCC version you are using and I will try using your version on my next attempt.

FYI: I tried using the [code::blocks] default MinGW GCC compiler; instead of using the Cygwin GCC as I normally do.

What CB Compiler are you trying to edit to use the MSys2 GCC compiler?
What Msys2 GCC version are you using?

Edit: Decided my MSys2 installation might be corrupt deleting it and starting over.

Tim S.
« Last Edit: April 12, 2016, 03:00:42 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: wxWidgets don't work
« Reply #8 on: April 12, 2016, 03:42:24 am »
I succeeded; I had a cut/paste error that I did NOT notice for about 2 hours.

Link to my draft instructions https://github.com/stahta01/cb_misc/blob/master/Notes/CB%20setup%20for%20MSys2%20wxWidgets.txt

Edit: I used "Compiler Custom Variables" for the two variables that needed to have forward slashes because I had issues when I tried either CB Global vars or Project Custom vars.

Edit2: Build log
Code: [Select]
-------------- Clean: Debug in wx30Msys2 (compiler: GNU GCC Compiler MSys2 MinGW64)---------------

Cleaned "wx30Msys2 - Debug"

-------------- Build: Debug in wx30Msys2 (compiler: GNU GCC Compiler MSys2 MinGW64)---------------

x86_64-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps64/MSys2/mingw64/lib/wx/include/msw-unicode-3.0 -IC:/Apps64/MSys2/mingw64/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -fpermissive  -c C:/SourceCode/test/wx30Msys2/wx30Msys2App.cpp -o obj/Debug/wx30Msys2App.o
x86_64-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps64/MSys2/mingw64/lib/wx/include/msw-unicode-3.0 -IC:/Apps64/MSys2/mingw64/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -fpermissive  -c C:/SourceCode/test/wx30Msys2/wx30Msys2Main.cpp -o obj/Debug/wx30Msys2Main.o
x86_64-w64-mingw32-g++.exe  -o bin/Debug/wx30Msys2.exe obj/Debug/wx30Msys2App.o obj/Debug/wx30Msys2Main.o  -LC:/Apps64/MSys2/mingw64/lib   -pipe -Wl,--subsystem,windows -mwindows -lwx_mswu_xrc-3.0 -lwx_mswu_webview-3.0 -lwx_mswu_html-3.0 -lwx_mswu_qa-3.0 -lwx_mswu_adv-3.0 -lwx_mswu_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -mthreads 
Output file is bin\Debug\wx30Msys2.exe with size 866.95 KB
Process terminated with status 0 (0 minute(s), 8 second(s))
0 error(s), 0 warning(s) (0 minute(s), 8 second(s))

Tim S.

Deleted attachment because it is a waste of bandwidth to try to help this person we both speak English; but, we do NOT communicate.

« Last Edit: April 14, 2016, 01:59:51 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #9 on: April 12, 2016, 04:57:43 am »
Many thanks for that.  My dir structure is a little different, so I made the appropriate changes, but still failed.

1) My MSys2 Dir structure is shown in "wx MSys2 Dir struct 1.jpg" attached

2) I set the global vars as shown in "wx MSys2 Glb Var 1.jpg" attached.

3) My toolchain is as per "wx MSys2 Tool Chain 1.jpg" attached

4) I set the custom (toochain) vars as per "wx MSys2 Custom Var 1.jpg", attached.

5) When I try to create a project, it fails on the dialogue "wx MSys2 loc1.jpg", attached.


... so did not get to setting the project specific custom vars

... since I can only add two attachments at a time, I will add to the additional attachment to two Posts immediately following

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #10 on: April 12, 2016, 04:59:21 am »
attachments 3) and 4)

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #11 on: April 12, 2016, 05:00:03 am »
attachment 5) ... where it fails.

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: wxWidgets don't work
« Reply #12 on: April 12, 2016, 05:01:42 am »
BTW, and just be on the safe side, out intentions are to produce wxWidgets based GUI with code (e.g. HelloWorld) ... NOT COMPILE CB,

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: wxWidgets don't work
« Reply #13 on: April 12, 2016, 07:32:22 am »
I stated already that this is a project that might be able to use as a starting point as a template!
It does NOT fix the [code::blocks] wizard to work with MSys2!

Tim S.
« Last Edit: April 12, 2016, 07:34:08 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: wxWidgets don't work
« Reply #14 on: April 12, 2016, 08:44:39 am »
Edited CB Project attached as an zipped template.

Link to updated directions https://github.com/stahta01/cb_misc/blob/master/Notes/CB%20setup%20for%20MSys2%20wxWidgets.txt


Please try to run the CB Project after you unzip it.

Tim S.

Deleted attachment because it is a waste of bandwidth to try to help this person we both speak English; but, we do NOT communicate.
« Last Edit: April 14, 2016, 02:00:31 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org