User forums > Using Code::Blocks
wxWidgets don't work
stahta01:
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
--- End code ---
My output
--- Code: --- Default config is msw-unicode-3.0
Default config will be used for output
Alternate matches:
msw-unicode-static-3.0
--- End code ---
Tim S.
stahta01:
--- Quote from: 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.
--- End quote ---
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.
DrOli:
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.
BlueHazzard:
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
--- End code ---
this command was executed in a newly created "build_config" sub folder of the wxWidgets source folder. Then:
--- Code: ---make
--- End code ---
and
--- Code: ---make install
--- End code ---
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
--- End code ---
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"
DrOli:
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version