Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: DrOli on April 09, 2016, 04:08:22 am

Title: wxWidgets don't work
Post by: DrOli 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. 
Title: Re: wxWidgets don't work
Post by: MortenMacFly 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.
Title: Re: wxWidgets don't work
Post by: DrOli 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
Title: Re: wxWidgets don't work
Post by: stahta01 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.
Title: Re: wxWidgets don't work
Post by: DrOli 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.
Title: Re: wxWidgets don't work
Post by: BlueHazzard 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?
Title: Re: wxWidgets don't work
Post by: DrOli 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.
Title: Re: wxWidgets don't work
Post by: stahta01 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.
Title: Re: wxWidgets don't work
Post by: stahta01 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 (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
-------------- 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.

Title: Re: wxWidgets don't work
Post by: DrOli 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
Title: Re: wxWidgets don't work
Post by: DrOli on April 12, 2016, 04:59:21 am
attachments 3) and 4)
Title: Re: wxWidgets don't work
Post by: DrOli on April 12, 2016, 05:00:03 am
attachment 5) ... where it fails.
Title: Re: wxWidgets don't work
Post by: DrOli 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,
Title: Re: wxWidgets don't work
Post by: stahta01 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.
Title: Re: wxWidgets don't work
Post by: stahta01 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 (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.
Title: Re: wxWidgets don't work
Post by: DrOli on April 12, 2016, 09:58:09 pm
Many thanks for the very considerable effort you have provided, and thank you for the extra code.  We report on our findings, but really, it looks to us that the MSys2 approach is too heroic at this time, as discussed below.

We've performed various tests with the provided code. Though we are not sure we actually understand the manner in which the provide code is to be used:

1) Attempting to create a new project: we cannot get past the line 363, 1022 etc errors listed previously.

2) Copy the provided files to Templates, no apparent difference.

3) Copy the provided files to one of the "failed" earlier attempts to create a new wx project.  This actually launches a project, but then on attempting to compile there are all the same errors we spoke of in our previous experiments with MSys2, most notably, CB's expectation of Dir locations vs. what is actually on the machine, and detailed again in the P.S. below.  In addition, there were other "weirdness" as well, but leave those for another time.


We wonder if the "MSys2 experiment" is the best way forward, c.f. perhaps the traditional "CB specific" install approach might be more achievable.

Please keep in mind that all we really need at this point is a CB installation that can make use of standard wx for standard wx projects, such being able to do the "hello world" example here (http://wiki.codeblocks.org/index.php/WxSmith_tutorial:_Hello_world), which relies on a wx installation following the "CB Instructions" (and NOT MSys2), such as those here (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_%28MSW%29).

As previously, we were able to follow the "CB instructions" and completed the "make".  We have that entire "CB specific make" on the machine, and entirely independent of any MSys or MSys2 installation.  It has the monolithic dll, but we can't get CB to see the bits, perhaps due to the "CB make instructions" creating a dir structure that may not be suitable, or we have gone wrong somewhere without knowing it.

We don't understand why "CB instructions" then does not allow us to immediately perform the "tutorial", as should be possible according to CB web page.


Would it make more sense, and be less expensive and achievable, to get the "CB instructions" to work, rather than fork off on a completely different approach (e.g. MSys2)?   We don't even know enough to answer that question, so we are relying on CB's expertise.


Please advise on the least expensive direct route to have a sufficient CB/wx installation to perform, say, the CB wx hello world tutorial.


PS


Also, purely as a FYI, the MSys2 bit you had kindly produced, continues to look for wx.h in a dir called \include\wx.  Neither MSys2, nor a traditional build from scratch in classical MSys/MingW creates such a Dir.  Instead, those installs have a dir \include\wx-3.0\wx.  Thus, any and all of the CB/squirl etc bits that have lines like #include "include/wx" will fail, and/or require global replace of some sort.  There are other such examples, too, to be left for another day.

Also, Neither MSys2, nor a traditional build from scratch in classical MSys/MingW creates monolithic.  Which may explain the script/squirl errors, such as at line 1022, when testing the MSys."X" installs.
Title: Re: wxWidgets don't work
Post by: stahta01 on April 12, 2016, 11:54:34 pm
I give up because I am failing to communicate with you. I have no idea what I am doing wrong.
But, you give no info that help me help you.

Edit: IMHO, till you know how to create a CB Project that does what you want; you do NOT know enough to edit the CB Wizard to create the CB Project you want.

Edit2: How to use the project I attached as a zip file.
1. You unzip it.
1B. You edit the CB GCC Compiler so it has the correct compiler custom variable COMPILER_PREFIX
2. You open the project using Code::Blocks
3. You try to build the project.
4. You post the full re-build log to figure out what went wrong.

Edit3: Likely things to go wrong.
User failed to add "Additional path" needed to find the correct sh.exe
User failed to add the sed package to MSys2


Edit4: My own thread on CB wxWidgets Wizard http://forums.codeblocks.org/index.php/topic,21094.0.html (http://forums.codeblocks.org/index.php/topic,21094.0.html)

Tim S.
Title: Re: wxWidgets don't work
Post by: DrOli on April 13, 2016, 03:17:37 pm
I feel your frustration, but in all fairness, we have provided (MANY) detailed reports of exactly what went wrong and why, in which line, etc etc, and what effects various edits had.

... we have now 6-man-days into to this matter, and quite frankly that is a substantial investment considering that an alternative approach might get us to a working solution for much less expense.

... THAT IS why, we are thinking of "dumping the MSys2 approach", and asking about getting the "traditional CB specific wx" install (as per that CB official pages) working, but we don't know why that wont accept the dll's, as reported with some frequency in the previous submissions.



Having said so, and just to demonstrate again exactly what we had reported on multiple occasions, when we follow your (MSys2) instructions, as we had in the past, and showed screen prints (see previous submissions), and detailed reports etc, we repeated the entire process again.


1) Make sure all settings are as per your (MSys2) instructions (see previous screen prints)

2) Create brand new dir/unzip your files.

3) open project, make sure project specific settings are as per your instructions (see previous screen prints)

4) try to build:

... crashes on #include <wx/app.h> in wx30Msys2App.h (see attached log 1)

keeping in mind that the MSys2 (or any MingW) install has

D:\Apps\msys64\mingw32\include\wx-3.0\wx

,, NOT

D:\Apps\msys64\mingw32\include\wx

... so comment out orig line and make change as:


//DrO, #include <wx/app.h>
#include <wx-3.0/wx/app.h>

... no try build again,


... now it crashes in app.h, (see attached log 2, 3)

#include "wx/event.h"       // for the base class in App.h

... so try same trick above, comment out orig, and replace with adjusted

//DrO, #include "wx/event.h"       // for the base class
#include "wx-3.0/wx/event.h"       // for the base class

... now it crashes in event.h (see attached log 4, 5)

... so do same edit as before

//DrO, #include "wx/defs.h"
#include "wx-3.0/wx/defs.h"

... try build again,

... this goes on and on, exactly as it did in all the previous experiments, which we provided in detail in the previous submissions.


... DECIDED to set extra search path in Project compiler and linker settings: D:\Apps\msys64\mingw32\include\wx-3.0
... and also "undid" all of the custom edits above


... closed CB, and restarted CB

... tried to open project, this time, big surprise, get three dialogue boxes to the effect:

"cc1plus.exe - Unable to locate component"
"This application has failed to start because libgmp-10.dll was not found....."



All of this sort of behaviour had been reported repeatedly with repeated experiments in the past.  If you still think MSys2 is the way to go, OK, but we really need something that works soon ... remember, at this point we are just trying to see if we can get the CB Hello World Tutorial working.

... AND, please explain why we should not get the "traditional CB Specific" approach to work, instead of spending all this time/money on the MSys2 approach.

... in particular, if do this (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_%28MSW%29), then how come we can't this (http://wiki.codeblocks.org/index.php/WxSmith_tutorial:_Hello_world), particularly given the many results/tests etc we have submitted on that approach.



PS. as per usual the blog limits two achievements per post, so will need to add some posts for the entire collection of jpgs cited above.
Title: Re: wxWidgets don't work
Post by: DrOli on April 13, 2016, 03:18:22 pm
attachments 3, 4
Title: Re: wxWidgets don't work
Post by: DrOli on April 13, 2016, 03:25:14 pm
The blog is preventing the attachments/jpgs for some odd reason ... I'll try posting the jpgs later
Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 03:56:15 pm
Please read the Wiki and Post a build log!!! In code tags. http://wiki.codeblocks.org/index.php/FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F (http://wiki.codeblocks.org/index.php/FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)

EDIT: "Build Log" does NOT mean "Build Messages" Full means do a rebuild instead of build!

I do suggest that you give up; since posting a build log instead of a image is not possible for you; we do NOT want student to swamp this board with off topic questions and if the teacher can NOT figure out how to cut and paste a full build log then that is likely.

Edit2: I will try posting a new zipped project with troubling shooting output because learning to troubleshhot seems to be a forgotten art at most Colleges and other schools.
NOTE: This will NOT help me help you unless you can learn to cut and paste the full build log. So, if you fail after i post the new zipped project I will give up on you as a lost cause!!!!!

Tim S.
PS, I am NOT a CB dev; just someone losing my patience with a doctor who seems to be very smart and stupid at the same time!
Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 07:22:00 pm
This is a build log like I am hoping you post. I broke mine into two part the pre-build steps I added to determine the problem and the normal output of a build log.

Edit2: Added new zipped CB Project.
I ran into an issue that looked like your issue; exiting out of Code::Blocks fixed the cause of my issue.

Tim S.

Code
Running target pre-build steps
i686-w64-mingw32-g++.exe --version
i686-w64-mingw32-g++.exe (Rev5, Built by MSYS2 project) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
echo C:\Apps64\MSys2\mingw32\
C:\Apps64\MSys2\mingw32\
echo C:/Apps64/MSys2/mingw32
C:/Apps64/MSys2/mingw32
CMD /C where where
C:\Windows\System32\where.exe
CMD /C where sh.exe
C:\Apps64\MSys2\usr\bin\sh.exe
CMD /C "sh.exe -c 'which sed'"
/usr/bin/sed
CMD /C "sh.exe -c 'which wx-config'"
/mingw32/bin/wx-config
Code
-------------- Build: Debug in wx30Msys2 (compiler: GNU GCC Compiler MSys2 MinGW64 32 bit)---------------

i686-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps64/MSys2/mingw32/lib/wx/include/msw-unicode-3.0 -IC:/Apps64/MSys2/mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -mthreads -fpermissive  -c C:/SourceCode/OpenSourceCode/Apps/IDEs/CodeBlocks/cb_misc-git/Notes/MSys2/wx30Msys2/wx30Msys2App.cpp -o obj/Debug/wx30Msys2App.o
i686-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps64/MSys2/mingw32/lib/wx/include/msw-unicode-3.0 -IC:/Apps64/MSys2/mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -mthreads -fpermissive  -c C:/SourceCode/OpenSourceCode/Apps/IDEs/CodeBlocks/cb_misc-git/Notes/MSys2/wx30Msys2/wx30Msys2Main.cpp -o obj/Debug/wx30Msys2Main.o
i686-w64-mingw32-g++.exe  -o bin/Debug/wx30Msys2.exe obj/Debug/wx30Msys2App.o obj/Debug/wx30Msys2Main.o  -LC:/Apps64/MSys2/mingw32/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 796.98 KB
Process terminated with status 0 (0 minute(s), 9 second(s))
0 error(s), 0 warning(s) (0 minute(s), 9 second(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.

If another person wants the code it is located here the OP never even tried this code; reason unknown, likely failure to communicate. https://github.com/stahta01/cb_misc/tree/master/Notes/MSys2/wx30Msys2 (https://github.com/stahta01/cb_misc/tree/master/Notes/MSys2/wx30Msys2)
Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 09:17:14 pm
Example of a Bad Build Log; I had to exit out of Code::Blocks
because some changes only take effect after restart of CB.
Code
-------------- Build: Debug in wx30Msys2 (compiler: GNU GCC Compiler)---------------
i686-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g  -c C:\SourceCode\OpenSourceCode\VC_Repos\Apps\IDE\Codeblocks\cb_misc-git\Notes\MSys2\wx30Msys2\wx30Msys2App.cpp -o obj\Debug\wx30Msys2App.o
In file included from C:\SourceCode\OpenSourceCode\VC_Repos\Apps\IDE\Codeblocks\cb_misc-git\Notes\MSys2\wx30Msys2\wx30Msys2App.cpp:18:0:
C:\SourceCode\OpenSourceCode\VC_Repos\Apps\IDE\Codeblocks\cb_misc-git\Notes\MSys2\wx30Msys2\wx30Msys2App.h:13:20: fatal error: wx/app.h: No such file or directory
compilation terminated.

After restarting Code::Blocks; I have been told by CB Devs
 that closing the project should be enough to fix this issue; but, it has never worked for me.
 The issue is the the value between backticks is never updated in CB.
A Good build log.
Code
-------------- Build: Debug in wx30Msys2 (compiler: GNU GCC Compiler)---------------

i686-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps32/MSys2/mingw32/lib/wx/include/msw-unicode-3.0 -IC:/Apps32/MSys2/mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -mthreads -fpermissive  -c C:\SourceCode\OpenSourceCode\VC_Repos\Apps\IDE\Codeblocks\cb_misc-git\Notes\MSys2\wx30Msys2\wx30Msys2App.cpp -o obj\Debug\wx30Msys2App.o
i686-w64-mingw32-g++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -IC:/Apps32/MSys2/mingw32/lib/wx/include/msw-unicode-3.0 -IC:/Apps32/MSys2/mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -mthreads -fpermissive  -c C:\SourceCode\OpenSourceCode\VC_Repos\Apps\IDE\Codeblocks\cb_misc-git\Notes\MSys2\wx30Msys2\wx30Msys2Main.cpp -o obj\Debug\wx30Msys2Main.o
i686-w64-mingw32-g++.exe  -o bin\Debug\wx30Msys2.exe obj\Debug\wx30Msys2App.o obj\Debug\wx30Msys2Main.o  -LC:/Apps32/MSys2/mingw32/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 796.98 KB
Process terminated with status 0 (1 minute(s), 39 second(s))
0 error(s), 0 warning(s) (1 minute(s), 39 second(s))

Tim S.
Title: Re: wxWidgets don't work
Post by: DrOli on April 13, 2016, 10:04:23 pm
While we certainly do appreciate your extra effort, I am not sure if this is the best way to go about it.

Once again, and have asked many times, why is it that we can't simply get the "CB specific wx install" as per the CB pages, that accompany the CB tutorial for wx?   Why are we still, and ONLY, breaking our heads over a completely different approach via MSys2?  It is clear from the CB pages cited, that CB's "special wx make" approach is their required practice, and one that is, in a way, at odds with an MSys2 approach.

... perhaps we should switch to that, or involve somebody who is willing to do so.

Having said so, your last couple of posts are highly inappropriate, and out of line, and I add a comment in the P.S.

As a matter of courtesy, we performed yet another completely from scratch test based on your MSys2 approach just for you.  The build log:


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

Cleaned "wx30Msys2 - Debug"

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

i686-w64-mingw32-c++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g  -c E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.cpp -o obj\Debug\wx30Msys2App.o
In file included from E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.cpp:18:0:
E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.h:13:20: fatal error: wx/app.h: No such file or directory
compilation terminated.
Process terminated with status 1 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))



If we close CB, re-launch, open project, and re-build, the build log:


-------------- Clean: Debug in wx30Msys2 (compiler: GNU GCC Compiler)---------------

Cleaned "wx30Msys2 - Debug"

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

i686-w64-mingw32-c++.exe -Wall -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -g -I/lib/wx/include/msw-unicode-static-3.0 -I/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -D__WXMSW__  -c E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.cpp -o obj\Debug\wx30Msys2App.o
In file included from E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.cpp:18:0:
E:\FORTRAN\CodeBlocks\wxHW30_5\wx30Msys2App.h:13:20: fatal error: wx/app.h: No such file or directory
compilation terminated.
Process terminated with status 1 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 
 


... that's it, straight from CB's Build Log window.   There is no obvious place in CB that we could find that speaks of "pre build", and it's not on the page you cited either.  So, if you would like one of those, please be specific about creating one.

If there is another way to create build logs, please be specific about that, there is certainly nothing more than what we have done on the page you cited.


Finally, while we are happy to test a little more with this MSys2 strategy of yours, we really think that exploring that "CB official/specific" approach is worthy of attention, and wonder if you would speak to that.



P.S.  We will let it go this time, but you may wish to take more care before calling people "stupid".   We have been doing mathematical modelling and computational mathematics for many decades.  I am certain I could find an infinite number of computational problems, such as solving PDE's, stochastic calculus, differential topology, etc etc, where, even though you may have many years of programming experience, and higher education ...  you would not stand a chance, at least not without considerable assistance.

We have never seen wx before, we don't know anything about CB's "inards" and scripts etc, this is our very first go at creating a wx gui, and we can't even get CB to start the project, even for the "Hello World Tutorial" on CB's pages, in spite of following the instructions to the letter, and many times.

...  we don't think it is unreasonable to be able to get CB to do what it says it can do on its own pages.

... There is a very big difference between stupid, and uninitiated/inexperienced with a narrow/specialised technical subject.
Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 10:07:28 pm
Please download the CB Project that I wasted two hours to add the prebuild steps to.

http://forums.codeblocks.org/index.php/topic,21085.msg144058.html#msg144058 (http://forums.codeblocks.org/index.php/topic,21085.msg144058.html#msg144058)

Tim S.
Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 10:15:27 pm
Please state the type of wxWidgets library you are wanting to use?
Shared or Static?
wxWidgets version?

Are you planning to use Code::Blocks wxSmith to create the GUI for your students?

Remember I still NEED the output of the CB Project pre-build commands.

If you know how to use the wx-config command; please post the output from MSys2 Mingw prompt.

Code
wx-config --list 

My output
Code
    Default config is msw-unicode-3.0

  Default config will be used for output

  Alternate matches:
    msw-unicode-static-3.0

Tim S.

Title: Re: wxWidgets don't work
Post by: stahta01 on April 13, 2016, 10:23:54 pm
While we certainly do appreciate your extra effort, I am not sure if this is the best way to go about it.

Once again, and have asked many times, why is it that we can't simply get the "CB specific wx install" as per the CB pages, that accompany the CB tutorial for wx?   Why are we still, and ONLY, breaking our heads over a completely different approach via MSys2?  It is clear from the CB pages cited, that CB's "special wx make" approach is their required practice, and one that is, in a way, at odds with an MSys2 approach.

... perhaps we should switch to that, or involve somebody who is willing to do so.

Having said so, your last couple of posts are highly inappropriate, and out of line, and I add a comment in the P.S.

Please decide what you want to do.

You can give up using Code::Blocks; which I think might be best.
But, the fault is that Code::Blocks is NOT magic; it can NOT do what you tried to do.
But, with a little effort you might be able to do it; but, I have no idea what you really want to do.

I say again till you can get a CB Project to do what you want you will just be wasting time to try to get the wizard to do what you have no idea of how to do!

The CB windows way of using wxWidgets does NOT use wx-config that is MOST of your problem.
Code::Blocks also offers very poor support of CygWin which is another reason NOT to use it; MSys2 is a port of Cygwin.

Getting CB to use MSys2 debugging will likely be very hard to do; but, should be a little easier than getting a Cygwin debugger to work under CB.

Since, your post say you no longer want my help; I will do what you want and stop helping you.

Tim S.
Title: Re: wxWidgets don't work
Post by: DrOli on April 14, 2016, 01:10:50 am
Dear Mr Tim.S

We were rather dismayed with your latest response. 

1) First and foremost, and very much in contradiction of your remarks, we have ALWAYS been CLEAR, and REPEATED at least SEVEN times, in virtually every post we have placed that our objective is to be able to do the CB wx TUTORIAL on this page (http://wiki.codeblocks.org/index.php/WxSmith_tutorial:_Hello_world), on which there is link for installing wx for CB on this page (http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_%28MSW%29).

Those posts, and those pages, and repeated various times, directly state the type of library required by the "CB instructions", and which we have noted may be at odds with the MSys2 approach that you are insisting on.

You have not on a single occasion commented in any way on those objectives or install, instead you have always restricted you attention solely to an MSys2 approach, and in spite of our repeated requests for you to consider the "official CB instructions/approach".  Have you ever even looked at those CB pages?

For you to say that you don't know what our objectives are rather speaks badly for your character.


2) Second, we have NOT ever asked you NOT to work on this matter, and again the facts contradict your remarks.  Though we have repeatedly, and virtually in every post, asked that you consider the "official CB approach", but which you have not.  Based on your comments, we can now only conclude that you are unwilling to do so.  Though we don't understand why you would not have just said so from the outset.


So, PLEASE have the good manners to ask one of the CB people/developers to respond ... as this type of "throwing us to dogs" seems decidedly unprofessional.



I will leave the MAIN points at that for now, but for the record just few of the additional matters include:

0) we have no idea what many of your other remarks mean, such as your reference to "our students", etc, nor why or where such ideas would come from.

1) It seems ridiculous to suggest that we do not use CB.  The entire OBJECTIVE here is to do the CB wx Tutorial.

2) You remark regarding MSys2 debugger etc are groundless and contradicted by the facts.  We have developed computational code, also Excel add-ins with CB/Fortran, and various other bits via CB/GTK/GTKExtra/GTKFortran etc.  The MSys2 debugger and ToolChain is actually the most up to date available to us, and it works very well in CB, even when debugging complex/mixed-language matters like Excel/VBA/Fortran/DLL's.

3) Clearly, it is possible to get wx to work in CB, as demonstrated by the TUTORIAL.  So, all we need is to figure out why the CB instructions need adjustment to work here.

4) It seems rather interesting that you would highlight just a portion of one of our posts, and "cheery picked" only a portion of our comments.  That, whether intended or not, is rather misleading.  For example, you don't see us cheery picking out your "stupid" statements etc.

5) We were willing to/and have put in a huge investment in your continued insistence on an "MSys2 only" approach, so long as that approach produced the objectives repeatedly stated.  Apparently, now that you are not willing or able to complete even that, you now seem to be posturing with dubious or imagined issues, so to fabricate an excuse to "throw us to the dogs".

... and so on.




Once again, PLEASE be so kind as to either provide a solution, for the now repeated ad nauseum times, to get us to be able to run the CB wx Tutorial ... or I suppose, given the nature of your responses and the character you have displayed recently, please have the good manners to ask someone at CB to provide the solution to allow this investment to complete.
Title: Re: wxWidgets don't work
Post by: BlueHazzard on April 14, 2016, 01:20:18 pm
So lets look if i can clear you up:
1) The wizard of c::b does NOT work with the current wx3.x installation without modifying. The reasons are because there are some highly complex naming conventions for wx libraries, and the current implementation of the script wizard is not build to handle this.
2) Don't try to modify the wizard script. My impression from your posts is that you are not experienced by compiling, because if you where, this thread would be finished after 3 posts... As stahta01 says here http://forums.codeblocks.org/index.php/topic,21094.0.html it will take some over thinking and probably some moths until the script is prepared for this and hopefully future wxWidgets versions
3) Sadly the wiki is not as up to date as it should be, so don't think that all instructions are cast in concrete. As i mentioned above wxWidgets uses a highly complex naming scheme so it is probably that the naming are different on your system.


Ok, if you want only to get a compilable project with wxWidgets, not really flexible, you only need some time to follow this steps:

Pre steps:
i have build wxWidgets with Msys. My configure command line was as follow:
Code
../configure --enable-debug --prefix=../config_install
this command was executed in a  newly created "build_config" sub folder of the wxWidgets source folder. Then:
Code
make
and
Code
make install
After this the config_install folder will have this structure:
Code
  .
   |-bin
   |-include
   |---wx-3.0
   |-----wx
   |-lib
   |---wx
   |-----config
   |-----include
   |-------msw-unicode-3.0
   |---------wx
   |-----------msw
   |-share

NOTE: I don't copy or install this to the mingw base folder. I don't like to mix all kind of libraries, because this makes things a lot more difficult if something goes wrong (mixing versions, compiler ecc.)...

So lets create a project:
1) Start C::B
2) File->New Project->wxWidgets project
3) choose wx version 3.0.x
4) enter project title
5) select wxSmith and Dialog based
6) Let the wx location, it is not importand...
7) Finish the wizard.it does not really mater what you are using, we will overwrite it later
8) There will be warning messages, you can ignore them (answer with yes)
9) The wizard will now create a project and it will NOT COMPILE
We will now set up the project:
10) Project->Build options
11) Select the top most item in the left tree view
12) Search directories-> Compiler
      a) Delete all entries
      b) Add entry-> Browse to your "config_install\include\wx-3.0" folder NOTE: this folder can have a other name on your system, like "config_install\include\wx-3.1" or "config_install\include\wx-3.0u", but i hope you get the idea what folder i mean...
      c) Add entry-> Browse to your  "config_install\lib\wx\include\msw-unicode-3.0" folder
13) Search directories -> Linker
      a) Add entry->Browse to your "config_install\lib" folder
NOTE: There will pop up many error messages "You have changed some settings. Do you want these settings to be saved?" Hit always "yes"
14) Linker Settings->Link libraries
      a) remove all libraries
     b) Add->Browse to your  "config_install\lib\" folder, select your "libwx_mswu_core-3.0.dll.a" NOTE: This file can have a other name on your system!! You need to select the file with "core" in it. OK->Use absolute paths-> Remove the path to only have the library name
     c) Add->Browse to your  "config_install\lib\" folder, select your "libwx_baseu-3.0.dll.a" NOTE: This file can have a other name on your system!! You need to select the file with "base" in it. OK->Use absolute paths-> Remove the path to only have the library name
15) In the Tree view on the left select "Debug" target
      a) Linker Settings->Link libraries-> remove all libraries
16) In the Tree view on the left select "Release" target
      a) Linker Settings->Link libraries-> remove all libraries
17) Hit OK
18) Build->Build and Run

This should create the "Hello world" example and it will run...
This is the simplest project. If you use some more complex ui elements you have to add the libraries under "Linker Settings->Link libraries"
If you update wxWidgets this project won't compile any more, because the names will probably change.
If you want a more flexible way, and templates for your projects use stahta01's template project. He uses a more general way, but it will add some complexity

This is a general tutorial. If you compiled wxWidgets with Msys, mingw or cygwin should not matter... Just use the --prefix options on the configure step so you KNOW where the libraries and include directories are... If you don't use the configure step, but the general makefile the instructions are similar, you just have to know where the libraries are and modify the paths accordingly...

I hope this will clear things up. If you have some problems compiling post a "FULL REBUILD LOG"
Title: Re: wxWidgets don't work
Post by: DrOli on April 15, 2016, 04:34:21 pm
Many thanks for the detailed notes. 

Though, first, it seems obligatory to add that your comment about us not knowing about compiling is specious.  In fact, the approach you have described is the exact approach we take with each and every project we have build since all of our project interlace many bits like C, Fortran, GTK, GTKExtra, PLPlot etc.  Therefore, it is a necessity and standard practice for us to be setting many compiler/linker/search dir's libs etc etc for every project and target.  We are confident that had your approach to circumventing the wizard been provided at the outset, we would have succeeded a very long time ago.

The problem here is NOT with compiling, but with:

1) As you have recognised, though in our view with spectacular understatement, the CB notes on the web certainly contribute to the confusion and clearly are self-inconsistent with the approaches offered on the forum pages.

2) However, by far a bigger problem is the "wx Wizard", as it relies on much specialised and internal machinery that certainly creates and exacerbates problems, and that has nothing to do with "compiling", but a lot to do with proprietary CB machinery.  Much time was spent dealing with what you now describe as will require many months of development work to get corrected.

3) The earlier suggestions for us to edit the Wizard were really sub-optimal and it seems a cul de sac.  The entire Tim.S "wx-config" approch, while it may, given enough time, be the strategy that the CB Wizard re-write may use etc, is MUCH too complex, much too delicate, and has far too many bits that require highly specialised knowledge of a very narrow matter.  It is certainly not an approach that should be recommended to any body other than seasoned specialists in that specific narrow area.

The best practical solutions, from our perspective, are provided below, with or without the wizard.


Now, GOOD NEWS:

1) We have figured out how/why to get both wx2 and wx3 working, from either a classical Msys install, or via the "CB specific" install.

Though, we can get the "full CB/wxWizard" approach to work only with wx2 and the CB specific "make" approach, and then with some adjustments.

All the other variations require circumventing the wizard via a process similar to, but not exactly as per, your instructions. 

All of the working results require some extra details, some of which are provided below.

That we had suspected from the outset, and as you have just recently confirmed, wx3 does NOT work with the Wizard (and as you say will require months of dev time) is a little annoying.  Had that point been made immediately at the outset, much time and agro would have been saved.  Similarly, had there been fewer "inconsistencies" on the CB pages for "monolithic" etc, that too would have saved much confusion, etc.

... it would seem pressing to put a short, but prominent, CAVEAT on the CB pages regarding such points.


2) Regarding some issues to get things working:

a) The wx install process has a number of idiosyncrasies, and especially its reliance on unorthodox Dir structure/location of files.  The most frequent error that arose in the many days we have spent on these matters is the compile crashing on "can't find wx/setup.h".  There are many setup.h's in the wx include/ sub dirs, but NONE in "wx".  That wx3 adds the extra dir "layer" /wx-3.0 very much exacerbates the issues, and also may be a key reason why CB's Wizard requires a re-write.

There are two important points that may help many:

(i) The "ACTUAL" setup.h that is required is, based on wx's "design", is actually located in ..\lib\gcc_dll\mswu\wx  ( NOT ..\include\wx...).  That one bit of information would have saved us many many hours.

(ii) Another important wrinkle is the "ORDER" in which paths etc are placed in the Search Directories etc in CB.  The Wizard, and variations of your approach will CRASH, even if the Search Dir have ALL the correct paths stated, but in the wrong order.  For example, when it searches for setup.h, if the first path does not include it, it may crash (i.e. need to use those little up/down arrows in the Search Dir dialog). 


b) Some of the instructions on CB pages are inconsistent.  For example, the make instructions are for unicode, but the TUTORIAL fails to show in its images/notes that in the Wizard that one must select/enable the unicode option in the Wizard.  Otherwise, one obtains some cryptic errors which are difficult to debug, and takes a little time to observe that if it is complaining about "Chars", but the make was Unicode, then its a Wizard/unicode/ansi "collision".

c) In your instructions, the "../configure --enable-debug --prefix=../config_install" fails with "configure: error: expected an absolute directory name for --prefix: ../config_install".  That could be a Unix vs. MSys thing.  We simply changed the build to a traditional MSys approach, and altered the names/paths as appropriate to test your instructions (though keeping point b) from above in mind).

d) We are not sure why, but the choice of ToolChain makes a difference.  On our system, we have two completely independent MinGW infrastructures:  One based on a somewhat traditional MinGW, where we build everything from scratch, and also an MSys2 install with all of its pre-built packages.  We had switched to the MSys2's Toolchain for compilers/debuggers since they are more recent compared to the MinGW-64 independent toolchain, and that works much better for all our C/Fortran/GTK etc projects (in fact bugs in GDB < 7.11.1 cause various type crashes for particular situations in CB, as reported elsewhere)

However, for these wx matters, some of the problems seemed to be due to "mystery" issues with the MSys2 Toolchain.  Those problems went away when we reverted (just for the wx testing/projects) to the classical Toolchain in MinGW GCC.  Ultimately, this could be a "path thing", but haven't proven the cause yet.

e) The choice whether to use .PCH or not impacts matters in various ways, and can lead to various compile issue, adding to the confusion.

f) The installation of wx 2.8.11 via the "CB specific" make instructions require a little jiggery pokery on windows < Win7/Sp1.  We can post our "fiddling" to make that work, let me know.

g) The CB instructions may wish to include a comment about the "j" switch, as it can massively increases speed of the, otherwise ponderous, make process on multi cpu machines.

h) The CB instructions for use with wx 3.x, for us, required adding CXXFLAGS=-std=gnu++11 to the make instruction (NOTICE, it MUST BE gnu++11, NOT c++11, this is some wx specific idiosyncrasy)

i) BTW, in your instructions, the example is for "Dialog", while the Tutorial is for "Frame", we assume that is purely incidental/context specific.  If there is more to that, please explain.

... various other minor matters for another time.



So, while it took two-man-weeks of fiddling to get CB/wx to work, once working it required only an hour to build a simple wx spreadsheet app, without any previous wx training ... very cool :-), we will test further to compare wx to Tcl and GTK.



3) A few questions:

a) Is there any specific reason why the CB wx instructions are for "release" only?

b) Is PCH always recommended for wx projects?  Perhaps a few words on the pros/cons may be helpful.

c) Is a "static" variation of all this possible/advisable?  For example, to simplify the distribution of apps produced (not sure about licensing implications??).

d) Is unicode necessary?  Perhaps a few words on the pros/cons may be helpful.

f) Perhaps a few words on the pros/cons of the "monolithic" wx approach vs. not may be helpful.


Many thanks

DrO
Title: Re: wxWidgets don't work
Post by: BlueHazzard on April 15, 2016, 11:47:29 pm
You should be able to edit the wiki (at least before the forum and wiki update it was possible to edit the wiki with the forum user) so you can update the wiki according your way and help other. The whole codeblocks project is made by volunteers and  all do their best, but there are to few people and they have not enough time to update the wiki every time something changes. This is for sure a grievance, but time is precious nowadays, and for my part i spend a lot here in the forum to help people...


Quote
c) Is a "static" variation of all this possible/advisable?  For example, to simplify the distribution of apps produced (not sure about licensing implications??).
Yes it is possible... just compile wxWidgets as static and use the static libraries. But the Wizard will not work with wx3.0

Quote
d) Is unicode necessary?  Perhaps a few words on the pros/cons may be helpful.
I don't know your mother-language, or your target language, but not everyone can speak english and so you will need other glyps than the standard aschii and for this you will need unicode. wx3.0 is compiled by default with unicode enabled...