Compiled wxWidgets executables will not run.

[jon4514]

All,


I successfully compiled wxWidgets and pointed Code::Blocks to the appropriate directories.  Using the wizard, I then created the simple example wxWidgets program.  The program compiles without error or warning using the default wizard settings.

When executing the program, windows says that the wxWdigets dll is a "invalid windows image."  Does anyone know what could be the cause of this?  I have tried recompiling everything but the error keeps occurring.

I may have done something stupid as this was my first time using wxWidgets with Code::Blocks in windows.

I am using:
-code::blocks nightly build revision 3803
-wxWidgets 2.8.5 with the following build command: mingw32-make.exe -f makefile.gcc USE_XRC=1    SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
-wxWigets was compiled using:
GNU Make 3.81
gcc version 4.2.1-dw2 (mingw32-2)
-Operating system: Windows XP Pro Tablet Edition

Thanks in advance,
Jonathan

[stahta01]

wxWidgets 2.8.5 has issues, so might wish to try 2.8.4 or if you wish to try the pre-released 2.8.6.

I have no idea if dw2 can cause issues, but I think you would need to compile both wxWidgets and your project using dw2 for it to have a chance to work right. If they are not the same issues WILL likely happen.

Tim S

My test results
Good with C::B SVN 3803, wxWidgets 2.8.6, compiled by MinGW 3.4.5 and Project compiled by MinGW 3.4.5
Good with C::B SVN 3803, wxWidgets 2.8.6, compiled by MinGW 3.4.5 and Project compiled by MinGW 4.2.1-sjlj
Good with C::B SVN 3803, wxWidgets 2.8.6, compiled by MinGW 3.4.5 and Project compiled by MinGW 4.2.1-dw2-2
Good with C::B SVN 3803, wxWidgets 2.8.5, compiled by MinGW 3.4.5 and Project compiled by MinGW 4.2.1-dw2-2

I do not see the problem with the default wxWidgets code, so done testing.

[stahta01]

How sure are you that your minGW installation was done correctly?

My Bat to report on MinGW Installation "version-of-mingw.bat"

Code

@echo off
REM credit to Peter Ward work in ReactOS Build Environment RosBE.cmd it gave me a starting point that I edited.
::
:: Display the current version of GCC, ld, make and others.
::

REM %CD% works in Windows XP, not sure when it was added to Windows
REM set MINGWBASEDIR=C:\MinGW
set MINGWBASEDIR=%CD%
ECHO MINGWBASEDIR=%MINGWBASEDIR%
SET PATH=%MINGWBASEDIR%\bin;%SystemRoot%\system32
if exist %MINGWBASEDIR%\bin\gcc.exe (gcc -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%\bin\gcc-dw2.exe (gcc-dw2.exe -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%\bin\gcc-sjlj.exe (gcc-sjlj.exe -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%\bin\nasm.exe (nasm -v)
if exist %MINGWBASEDIR%\bin\ld.exe (ld -v)
if exist %MINGWBASEDIR%\bin\windres.exe (windres --version | find "GNU windres")
if exist %MINGWBASEDIR%\bin\dlltool.exe (dlltool --version | find "GNU dlltool")
if exist %MINGWBASEDIR%\bin\pexports.exe (pexports | find "PExports" )
if exist %MINGWBASEDIR%\bin\mingw32-make.exe (mingw32-make -v | find "GNU Make")
if exist %MINGWBASEDIR%\bin\make.exe (ECHO It is not recommended to have make.exe in mingw/bin)
REM ECHO "The minGW runtime version is the same as __MINGW32_VERSION"
if exist "%MINGWBASEDIR%\include\_mingw.h" (type "%MINGWBASEDIR%\include\_mingw.h" | find "__MINGW32_VERSION" | find "#define")
if exist "%MINGWBASEDIR%\include\w32api.h" (type "%MINGWBASEDIR%\include\w32api.h" | find "__W32API_VERSION")

PAUSE

My results

Code

MINGWBASEDIR=C:\Apps\MinGW_GCC4
gcc version 4.2.1-sjlj (mingw32-2)
gcc version 4.2.1-dw2 (mingw32-2)
gcc version 4.2.1-sjlj (mingw32-2)
GNU ld version 2.17.50 20060824
GNU windres 2.17.50 20060824
GNU dlltool 2.17.50 20060824
GNU Make 3.81
#define __MINGW32_VERSION 3.13
#define __W32API_VERSION 3.10
Press any key to continue . . .

[eckard_klotz]

Hello Jonathan.

I have also some problems to run a wxWidgets application build with code::blocks. I use the wxWidgets 2.8.4 devpak from here http://devpaks.org/. installed with the original devpak-tool. I also get no errors or warnings. But if I use wxTextCtrl, the program ends with an abnormal termination (on WinXP).

If I compile the same program with wxDevC++ (http://wxdsgn.sourceforge.net/) everything works fine. So may be this is a good opportunity to check if your problem is coursed by your source, the wxWidgets-library or by the IDE.

I think for my problem the course is a wrong setup of the project in C::B. But until now I didn't found out what it is.

Regards,
              Eckard Klotz.

[Biplab]

If I compile the same program with wxDevC++ (http://wxdsgn.sourceforge.net/) everything works fine. So may be this is a good opportunity to check if your problem is coursed by your source, the wxWidgets-library or by the IDE.

You should remember one point. Your IDE is not responsible for your good or bad program. IDEs are interface to the compilers and it solely depends on the users how they drive the compiler through IDE. So if you use garbage settings, you'll get a garbage output (exe file in this case).

If I remember correctly, wxDevC++ comes with GCC-3.4.2 (MinGW build). Your program works with it as this compiler is pretty old and people are already aware of it's shortcomings and problems; and they consider these problems while writing a library such as wx. Thus you don't face much problem with it.

I am using:
-code::blocks nightly build revision 3803
-wxWidgets 2.8.5 with the following build command: mingw32-make.exe -f makefile.gcc USE_XRC=1    SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
-wxWigets was compiled using:
GNU Make 3.81
gcc version 4.2.1-dw2 (mingw32-2)
-Operating system: Windows XP Pro Tablet Edition

Downgrade your compiler to GCC-3.4.5 and then clean compile wx and your project. It should work then. Please note that GCC-4.2.1 is a technology preview release not a stable one and you may encounter many unknown problems with it.

[jon4514]

All,


I agree with the last post.  I do not think that it is an IDE problem.  But, I also do not think that it was a problem with my source because the wizard generated example would not work.  I think the key is that you have to get wxWidgets compiled with the correct configuration and use the correct settings in the IDE.

I figured out my problem thanks to Tim (thanks for getting me out of the rut I was stuck in).  I had been using a setup of Code::Blocks that had a lot of utilities with it in a folder I carried around on a portable hard drive.  When I switched to use wxWidgets code in windows, I copied this folder to my hard drive and tried to fix the compiler settings to point to a new compiler installed locally.  The problem is that the settings reverted back the to old complier in the the Code::Blocks directory.  The effect was that I was compiling wxWidgets with a much newer GCC than my codes compiled in code::blocks.  I definitely think (I am not an expert on Code::Blocks or xxWidgets) that wxWidgets should be compiled with GCC 3.4.x and not 4.2.  When I used 4.2, I would get a lot of warnings where as 3.4.x compiled with few warnings.

After fixing the compiler configuration and recompiling wxWidgets, the basic wxWidgets example worked fine.  All that is left for me to do figure out what changes were made to the new version of wxWidgets that keep my old code from compiling in Windows (but this certainly isn't appropriate for the C::B forms).

In the end I used:
wxWidgets 2.8.4 compiled in GCC 3.4.4.


Thanks everyone for your help,
Jonathan

[Biplab]

When I used 4.2, I would get a lot of warnings where as 3.4.x compiled with few warnings.

Add -Wno-attributes to the command line. This would reduce the warnings.

Code

mingw32-make -f makefile.gcc CXXFLAGS="-Wno-attributes" ...

Replace ... with rest of the command line.

[eckard_klotz]

Hello Biplab.
Don't take me wrong, I din't want to say use DevCpp instead of Code::Blocks. You are absolutly right if you say:

You should remember one point. Your IDE is not responsible for your good or bad program. IDEs are interface to the compilers and it solely depends on the users how they drive the compiler through IDE. So if you use garbage settings, you'll get a garbage output (exe file in this case).

But if I use an alternative IDE to complie my sources and the program works I don't have to search the error in my source-code, do I?

It took me long frustrating time to find out, that the reason was not a change in wxWidgets-functionalty (because evrything worked fine under wxWidgets 2.6.x).

Now I now I have to change the C::B project-settings (the "garbage settings" made by the project-wizzard of C::B). But it is possible to change all options? For example where do I change the wxWidgets library-settings I made with the project-wizzard? Why are the library-names inserted by the wizzard not the same as in the lib-directory?

Regards,
           Eckard Klotz.

[Biplab]

Now I now I have to change the C::B project-settings (the "garbage settings" made by the project-wizzard of C::B). But it is possible to change all options? For example where do I change the wxWidgets library-settings I made with the project-wizzard? Why are the library-names inserted by the wizzard not the same as in the lib-directory?

I would like to see which library names are not matching with the libraries present in lib directory. Honestly, if there is any bug I'd be happy to fix it.

[eckard_klotz]

Hello Biplab


This are the library-names created by C::B (build 4421 fom Aug 28 2007)

libwxmsw28_xrc.a
 libwxmsw28_aui.a
 libwxmsw28_dbgrid.a
 libwxbase28_odbc.a
 libwxmsw28_media.a
 libwxbase28_net.a
 libwxmsw28_gl.a
 libwxmsw28_qa.a
 libwxbase28_xml.a
 libwxmsw28_adv.a
 libwxmsw28_html.a
 libwxmsw28_core.a
 libwxbase28.a
 libwxpng.a
 libwxjpeg.a
 libwxtiff.a
 libwxzlib.a
 libwxregex.a
 libwxexpat.a

And this are the librarys in the lib-folder of the installed wxWidgets-devpak(2.8.4)

libwxexpat-2.8.a
 libwxjpeg-2.8.a
 libwxpng-2.8.a
 libwxregex-2.8.a
 libwxtiff-2.8.a
 libwxzlib-2.8.a
 libwx_base-2.8.a
 libwx_base_net-2.8.a
 libwx_base_odbc-2.8.a
 libwx_base_xml-2.8.a
 libwx_msw_adv-2.8.a
 libwx_msw_aui-2.8.a
 libwx_msw_core-2.8.a
 libwx_msw_dbgrid-2.8.a
 libwx_msw_gl-2.8.a
 libwx_msw_html-2.8.a
 libwx_msw_qa-2.8.a
 libwx_msw_richtext-2.8.a
 libwx_msw_xrc-2.8.a

Is there a posibility to adjust the default-names by myself? Because if you define them hard in the source-code and in the next devpak they change again you are the only one who can help.

Regards,
         Eckard Klotz.

[Biplab]

Is there a posibility to adjust the default-names by myself? Because if you define them hard in the source-code and in the next devpak they change again you are the only one who can help.

If I remember correctly the name of the libraries shipped with wxPack indicate that they are generated in MSYS using configure make process. This method is not supported by the wizard on Windows. If you use normal command line and make, you'll get the names that the wizard uses.

[rjmyst3]

If I remember correctly the name of the libraries shipped with wxPack indicate that they are generated in MSYS using configure make process. This method is not supported by the wizard on Windows. If you use normal command line and make, you'll get the names that the wizard uses.

wxPack builds with normal command line and make, and has names like "libwxmsw28_core.a". It works well with C::B.

Eckard is using "wxWidgets-devpak(2.8.4)", which I am not familiar with.

[Biplab]

wxPack builds with normal command line and make, and has names like "libwxmsw28_core.a". It works well with C::B.

Eckard is using "wxWidgets-devpak(2.8.4)", which I am not familiar with.

Thanks for correcting me. I didn't notice that he's using a devpak. I should sleep now.

I've used wxPack earlier and it works well with the wizard.