Are there DevPaks for wxWidgets 2.9.1? Topic is solved

[loucypher]

As in the subject... Have been compiled and made available the devpaks for wxWidgets 2.9.1?
Are they planned for some date?

~Lou

[NinjaNL]

As in the subject... Have been compiled and made available the devpaks for wxWidgets 2.9.1?
Are they planned for some date?

I can't speak for Tony, but I'll try to build something once wxW2.8.12 is released. I'll try and do both 2.8.12 and 2.9.1 to allow users to choose which they prefer. I'll also try and generate a definition file for the new styling names between 2.8 and 2.9 branches. Can't promise when. You could also try and build it yourself, there are a couple of stickies on the forum about how to do it.

[tbreina]

I have a devpak, but was waiting to post it as Robert and I are working on a new update to the IDE.

I can try to post the 2.9.1 devpak this weekend. However, there are a few caveats:

• 2.9.1 has thrown out some of the additional libs (I think the contrib).
  I have the Microsoft VC++ 2010 toolkit. So I'll be posting a wxWidgets devpak for that version rather than the 2008 toolkit. Sorry.
  2.9.1 is by default UNICODE. I'm planning to keep the devpak release as UNICODE even though prior devpaks have all been ANSI.

Again, as Mal pointed out, there's a primer on this forum about how to create the devpaks yourself to get exactly what you want. Also, we have a devpak maker batch file you could use (although I wish someone would step up and turn it into a nice GUI standalone).

-Tony[/list]

[loucypher]

Again, as Mal pointed out, there's a primer on this forum about how to create the devpaks yourself to get exactly what you want. Also, we have a devpak maker batch file you could use (although I wish someone would step up and turn it into a nice GUI standalone).

Oh ok, thanks for the (future) devpak and for the hint: I just suspect that I will have time to consider making the devpak myself in ages... and by then there will be an official 2.9.x devpak as well

~Lou

[tbreina]

I created DevPaks, but am having a devil of a time with them. I tried creating a simple wxFrame project. It compiles and runs, but the linker is giving me some warnings about undefined subroutines.

My hunch is that I'm missing a linker flag somewhere. The new 2.9.1 version is using Unicode and perhaps I need an extra switch or define or something.

Mal or loucypher, would you be able to test the DevPaks and help me look for the bug?

Thanks.
-Tony

Here are the DevPaks links. Once I get something correct, I'll post them to the webupdate.
http://wxdsgn.sourceforge.net/uploads/w ... mon.DevPak

http://wxdsgn.sourceforge.net/uploads/w ... gcc.DevPak

http://wxdsgn.sourceforge.net/uploads/w ... les.DevPak

[loucypher]

Don't know whether this has anything to do with your test... I just tried compiling an empty/fresh wxFrame project, after I updated the three devpaks:

- First time I clicked on "Run" I suddenly got an "Access violation at address 40005678 in module 'rtl60.bpl'. Read of address 7541733D", oops

- I stubbornly retried, this time compiled and linked with lots of errors

Just to try sorting things out, I tried a simple "Execute | Syntax Check", and I got back a lot of errors on missing header files (like wx/wx.h).
Looking better at compiler errors, I found g++ had troubles with spaces in directory names (yes, that should be already mentioned somewhere in MinGW docs), so it splits an included path as
-I"C:\Program Files (x86)\Dev-Cpp\lib\gcc\mingw32\3.4.5\include"
in a non existent C:\Program and a weird input file from the rest...

Anything similar that could have been happening on your side?

I'll reinstall wxDevCpp in another directory meanwhile, without any detrimental white spaces...

[tbreina]

- First time I clicked on "Run" I suddenly got an "Access violation at address 40005678 in module 'rtl60.bpl'. Read of address 7541733D", oops

That's a bug with the IDE. It shouldn't have anything to do with the devpak (I think).

- I stubbornly retried, this time compiled and linked with lots of errors

Just to try sorting things out, I tried a simple "Execute | Syntax Check", and I got back a lot of errors on missing header files (like wx/wx.h).
Looking better at compiler errors, I found g++ had troubles with spaces in directory names (yes, that should be already mentioned somewhere in MinGW docs), so it splits an included path as
-I"C:\Program Files (x86)\Dev-Cpp\lib\gcc\mingw32\3.4.5\include"
in a non existent C:\Program and a weird input file from the rest...

Anything similar that could have been happening on your side?

I'll reinstall wxDevCpp in another directory meanwhile, without any detrimental white spaces...

Not finding the wx.h include files means that something went wrong when installing the devpak. Can you confirm that the header files for wxWidgets (e.g. wx.h) were actually written to the directory? With Vista onward, Windows has a nasty habit of saying that it wrote a file when it actually wrote it to a temporary cache. Did the PackManager program ask you to elevate your permissions when you ran it?

-Tony

[loucypher]

Not finding the wx.h include files means that something went wrong when installing the devpak. Can you confirm that the header files for wxWidgets (e.g. wx.h) were actually written to the directory? With Vista onward, Windows has a nasty habit of saying that it wrote a file when it actually wrote it to a temporary cache. Did the PackManager program ask you to elevate your permissions when you ran it?
-Tony

My tests were completely unreliable: looks like I'm no more able to install wxDevCpp properly, here.
Note: running Windows 7 pro x64
Note: yes, wxDevCpp installer was run with admin privileges

I tried installing it, fresh clean, in the default "C:\Program Files (x86)\Dev-Cpp" or another directory like "C:\Develop\Dev-Cpp".
Tried both with the web based setup, or the stand-alone 7.3.1 installer.
Note: Clean 7.3.1 install, without any change/update.


When I create a new wxFrame project (in "C:/Temp/wxWidgets/wxf") all seems ok.
Header files are all where I would expect them to be (like "C:\Program Files (x86)\Dev-Cpp\include\common\wx\wx.h").
Note: unsure of what was happening I added an -I path to "C:/Program Files (x86)/Dev-Cpp/include/common", but without any difference

Then I just do a "Rebuild All" and in the compiler log I get something like

Code: Select all

Compiler: Default GCC compiler
Compiler: Default GCC compiler
Executing  g++.exe...
g++.exe "C:/Temp/wxWidgets/wxf/Untitled1Frm.cpp" -o "C:/Temp/wxWidgets/wxf/Untitled1Frm.exe"    -I"C:/Program Files (x86)/Dev-Cpp/lib/gcc/mingw32/3.4.5/include" -I"C:/Program Files (x86)/Dev-Cpp/include/c++/3.4.5/backward" -I"C:/Program Files (x86)/Dev-Cpp/include/c++/3.4.5/mingw32" -I"C:/Program Files (x86)/Dev-Cpp/include/c++/3.4.5" -I"C:/Program Files (x86)/Dev-Cpp/include" -I"C:/Program Files (x86)/Dev-Cpp/" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/msw" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/generic" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/html" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/protocol" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/xml" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx/xrc" -I"C:/Program Files (x86)/Dev-Cpp/include/common/wx" -I"C:/Program Files (x86)/Dev-Cpp/include/common"  -L"C:/Program Files (x86)/Dev-Cpp/Lib" 
C:\Users\[Me]\AppData\Local\Temp/cc6Lmt2u.o:Untitled1Frm.cpp:(.text+0x4d): undefined reference to `wxFrameNameStr'
C:\Users\[Me]\AppData\Local\Temp/cc6Lmt2u.o:Untitled1Frm.cpp:(.text+0x11e): undefined reference to `wxFrame::~wxFrame()'
C:\Users\[Me]\AppData\Local\Temp/cc6Lmt2u.o:Untitled1Frm.cpp:(.text+0x187): undefined reference to `wxFrameNameStr'
C:\Users\[Me]\AppData\Local\Temp/cc6Lmt2u.o:Untitled1Frm.cpp:(.text+0x258): undefined reference to `wxFrame::~wxFrame()'
...

If I just try a "Syntax Check" on Untitled1Frm.cpp I obtain

Code: Select all

Compiler: Default GCC compiler
Executing  g++.exe...
g++.exe "C:\Temp\wxWidgets\wxf\Untitled1Frm.cpp" -o "nul"    -I"C:\Program Files (x86)\Dev-Cpp\lib\gcc\mingw32\3.4.5\include" -I"C:\Program Files (x86)\Dev-Cpp\include\c++\3.4.5\backward" -I"C:\Program Files (x86)\Dev-Cpp\include\c++\3.4.5\mingw32" -I"C:\Program Files (x86)\Dev-Cpp\include\c++\3.4.5" -I"C:\Program Files (x86)\Dev-Cpp\include" -I"C:\Program Files (x86)\Dev-Cpp" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\msw" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\generic" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\html" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\protocol" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\xml" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx\xrc" -I"C:\Program Files (x86)\Dev-Cpp\include\common\wx" -I"C:\Program Files (x86)\Dev-Cpp\include\common"  -L"C:\Program Files (x86)\Dev-Cpp\Lib" 
In file included from C:\Temp\wxWidgets\wxf\Untitled1Frm.cpp:11:
C:\Temp\wxWidgets\wxf\Untitled1Frm.h:19:20: wx/wx.h: No such file or directory
C:\Temp\wxWidgets\wxf\Untitled1Frm.h:20:23: wx/frame.h: No such file or directory
...

As if it wasn't enough... on the first runs the IDE wasn't launching the compiler: I could see the progress dialog counting time, but there was no background compiler process, the count could go on for minutes (...)
At a certain point things changed, and the IDE started launching compiler, with the results above. I wish I could have a technical description for that certain point, but I don't...



For a conclusion, wrapping to beginning: I can't reliably test the library (and by now can't even recompile older projects...)

~Lou

[tbreina]

[quote="loucypher"]
Note: running Windows 7 pro x64
Note: yes, wxDevCpp installer was run with admin privileges

[\quote]

Ok, that might be a problem. wxDev-C++ is distributed with the MingW gcc compiler built for 32-bit systems. All of our libraries are also built for 32-bit. I have no idea if Windows 7 on a x64 will run the program correctly. In theory it shouldn't, but Microsoft might have put in some sort of compatibility layer for 32-bit stuff. If it does, then it probably won't generate native 64-bit programs for your system.

We'd love to upgrade, but so far we haven't had any 64-it developers step up to help (I don't even have a 64-bit computer).

-Tony

[NinjaNL]

Note: running Windows 7 pro x64
Note: yes, wxDevCpp installer was run with admin privileges[\quote]

Ok, that might be a problem. wxDev-C++ is distributed with the MingW gcc compiler built for 32-bit systems.[\quote]

Not necessarily, although the 3.4.5 compiler distributed with our development system DOES need replacing on a Win7/64 system (and probably should be in any case)

All of our libraries are also built for 32-bit. I have no idea if Windows 7 on a x64 will run the program correctly. In theory it shouldn't, but Microsoft might have put in some sort of compatibility layer for 32-bit stuff. If it does, then it probably won't generate native 64-bit programs for your system.

We'd love to upgrade, but so far we haven't had any 64-it developers step up to help (I don't even have a 64-bit computer).

-Tony

I have succeeded in getting wxDevCpp installed and working on a Win7/64 system. It does take a little playing around, but it does seem as if it's working correctly - as of today.

Firstly install wxDevCpp to a folder without brackets. Keep it simple and install it to c:/devcpp. The gcc compiler seems to have a problem when there are brackets in the PATH environment variable, or in paths being presented to it.

In windows explorer, right click on the c:\devcpp folder, select properties. Uncheck the read-only check box. This seems to get reset regularly. Although I don't believe that this is strictly necessary.

Select the security tab, select edit..., select users then select full control. Click on Apply, then OK.

Next, go to http://tdm-gcc.tdragon.net/download and download tdm-gcc-webdl.exe the on demand web based installer. Run it and create a 32 bit based compiler (I prefer to leave this residing at c:/mingw32). I might build some devpaks for it later, but at the moment it is simpler to leave it as it is.

Then remove the following packages
Binutils
gcc-core
gcc-g++
GNU-make
mingw-runtime
win32 api

I also removed all the wxWidgets packages, because I wanted to use both 2.8.12 and the current SVN in my projects. So I downloaded 2.8.12 and built it using this compiler. I could have built a devpak, but since I want to use two branches, I decided to leave it where it was and simply point wxDevCpp to it.

Next, in Tools/Compiler Options add a new compiler set (the green "plus" sign. I called this Mingw32. (Actually I called this MinGW32-wxWidgets2.8.12 since I used this compiler for the wxWidgets 2.8.12 build on my computer - I'll have other Compiler sets for other versions of wxWIdgets)

Now on the Directories tab, set contents to
Bin
C:\MinGW32\bin

Libraries
C:\MinGW32\bin
C:\wxWidgets-2.8.12\lib\gcc_lib

C Includes
C:\MinGW32\Include
C:\wxWidgets-2.8.12\include
C:\wxWidgets-2.8.12\lib\gcc_lib\msw

C++ Includes
C:\MinGW32\Include
C:\wxWidgets-2.8.12\include
C:\wxWidgets-2.8.12\lib\gcc_lib\msw

Resource Includes
C:\wxWidgets-2.8.12\include



Next we need to create a new project (or open an old one).
Once done, select Project/Project Options.

Ensure that the Project Profile is "MingW gcc 3.4.5", then press the rightmost button to duplicate the profile and give it a sensible name (in my case MinGW32-wxWidgets2.8.12)
Next select the Compiler tab, and in the Compiler drop down list, select the new compiler created above.

Next click on compile and run, Press F9 or whatever and your project should build and run correctly.

Note that this doesn't take into account the extra folders required for the contrib components and libraries nor the wxCode components and libraries. However the reasoning is the same, simply point the new compiler profile to the required locations and you should be OK.

[NinjaNL]

And of course I forgot the most important piece of information.

The GCC compiler has problems when there is a bracket in the path environment.

So we need to create a batch file

Code: Select all

set path=c:\mingw32\bin;
set wxdev=c:\dev-cpp
cd %wxdev%
devcpp

Which does nothing else but run wxdevcpp in its own environment, without all of the contents of the system PATH environment variable.

I place a shortcut on the desktop which simply calls this batch file, and execute it when I want to use wxDevCpp.

[loucypher]

Well, I didn't think to the PATH variable on dev-cpp launch!
So I fixed that, with a dev-cpp.cmd script, similar to the one proposed (just used "start devcpp.exe" to avoid the background console window), and it all worked.
Almost.

With the PATH fixed, having installed the tools in a "clean" path (like "C:\develop\dev-cpp"), even the "default GCC compiler" was fine, with the supplied wxWidgets.
Then I tried latest TDM GCC, with wxWidgets 2.8.12 freshly recompiled, and it all went fine.
I did all that with an old project I had sitting there for two-three years, and I was really happy of it. That was Friday: today, maybe cause it's Monday, that same project, recompiles always to an executable that crashes all the time (...)
The crash is caused by an exception code c0000005.

Compiling that code on an XP machine, and reinstalling it on the 7 one, where I have all the other stuff I need, is really annoying. I'm tempted to give in and admit I can't support anymore this application I'm developing, but it's very frustrating.
After all I can't file a bug for "application compiled successfully only on Thursdays and Fridays"

~Lou

[NinjaNL]

Well, I didn't think to the PATH variable on dev-cpp launch!
So I fixed that, with a dev-cpp.cmd script, similar to the one proposed (just used "start devcpp.exe" to avoid the background console window), and it all worked.
Almost.

With the PATH fixed, having installed the tools in a "clean" path (like "C:\develop\dev-cpp"), even the "default GCC compiler" was fine, with the supplied wxWidgets.
Then I tried latest TDM GCC, with wxWidgets 2.8.12 freshly recompiled, and it all went fine.
I did all that with an old project I had sitting there for two-three years, and I was really happy of it. That was Friday: today, maybe cause it's Monday, that same project, recompiles always to an executable that crashes all the time (...)
The crash is caused by an exception code c0000005.

Compiling that code on an XP machine, and reinstalling it on the 7 one, where I have all the other stuff I need, is really annoying. I'm tempted to give in and admit I can't support anymore this application I'm developing, but it's very frustrating.
After all I can't file a bug for "application compiled successfully only on Thursdays and Fridays"

~Lou

You could send me the project, and I can take a look at it for you. Contact me via if you want to do this. I'll look into the crash myself.

[NickDX]

Here are the DevPaks links. Once I get something correct, I'll post them to the webupdate.
http://wxdsgn.sourceforge.net/uploads/w ... mon.DevPak

http://wxdsgn.sourceforge.net/uploads/w ... gcc.DevPak

http://wxdsgn.sourceforge.net/uploads/w ... les.DevPak

Do these DevPaks support wxPropertyGrid (as I think propgrid was included on commons after 2.9)?

I just installed them and my linker was sent to mars when I tried to run my project.
I don't know if I did something wrong, as I forgot to uninstall the the 2.8.2 version before installing this 2.9.1 pak.

[tbreina]

Do these DevPaks support wxPropertyGrid (as I think propgrid was included on commons after 2.9)?

Yes, but not in the RAD. So you can hand-code the wxPropertyGrid into your program, but we don't currently have a nice GUI to automatically create the code for you. (That's probably not a bad thing since the property grid is often used as a standalone window anyway.)

Also, to get rid of the linker warning, add the flag "wxNO_RTTI" to the preprocessor defines section in Project->Project Options.

-Tony