The wxWidgets 3.0 seems to have problem, or bug?

[ChunJiu]

Hi All,

The wxWidgets 3.0 seems to have problems, the problem does not appear in 2.8.

The TDM-GCC-64 compiled of 32bit code with the option -m32 under Windows64 will always be 0xc000007b error.

This windres also used --target = pe-i386 parameters, the compiler has succeeded. But the emergence of this 0xc000007b execution error.

The wxWidgets comes with examples you can reproduce the problem, for example: wxWidgets-3.0.2\samples\display.

In the same example wxWidgets 2.8.12 did not have this problem, it's correct.

=========================================================

For wxWidgets-3.0.2\samples\display.
In wxWidgets 3.0.2:

mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11 -IC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32\mswu -IC:\Project\wxWidgets-3.0.2\include" CPPFLAGS="-m32 -IC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32\mswu -IC:\Project\wxWidgets-3.0.2\include" LDFLAGS="-m32 -LC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

For wxWidgets-2.8.12\samples\display.
In wxWidgets 2.8.12 ( I modified the makefile.gcc adding parameters --target=pe-i386 ) :

mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11 -IC:\Project\WX_2_8\lib\gcc_dll_m32\mswu -IC:\Project\WX_2_8\include" CPPFLAGS="-m32 -IC:\Project\WX_2_8\lib\gcc_dll_m32\mswu -IC:\Project\WX_2_8\include" LDFLAGS="-m32 -LC:\Project\WX_2_8\lib\gcc_dll_m32" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

==========================================================

C:\Project\WX_2_8\samples\display>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Tools/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/4.
9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --build=x86_64-w64-mingw32 --e
nable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable
-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC -
-disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-d
ebug --enable-threads=posix --enable-version-specific-runtime-libs --enable-full
y-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-l
d --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm -
-with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://td
m-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.9.2 (tdm64-1)

[ChunJiu]

I tried to use the predefined symbols : CPP="gcc -E -D_M_IX86 -m32" ,
Problems remain ...

(This wxwidgets 3.0.2 libraries also recompiled.)

2015-03-17 22_48_32.png (4.66 KiB) Viewed 6446 times

===========================================================

rcdefs.h

# 1 "..\\..\\include\\wx\\msw\\genrcdefs.h"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "..\\..\\include\\wx\\msw\\genrcdefs.h"
# 11 "..\\..\\include\\wx\\msw\\genrcdefs.h"
#ifndef _WX_RCDEFS_H
#define _WX_RCDEFS_H

#define wxUSE_RC_MANIFEST 1
# 35 "..\\..\\include\\wx\\msw\\genrcdefs.h"
#define WX_CPU_X86
# 46 "..\\..\\include\\wx\\msw\\genrcdefs.h"
#endif

===========================================================

For wxWidgets-3.0.2\samples\display.

In the wxWidgets 3.0.2:

mingw32-make -f makefile.gcc CPP="gcc -E -D_M_IX86 -m32" CXXFLAGS="-std=gnu++11" CPPFLAGS="-m32 -ID:\Temp\wxWidgets-3.0.2\lib\dll_m32_n\mswu -ID:\Temp\wxWidgets-3.0.2\include" LDFLAGS="-m32 -LD:\Temp\wxWidgets-3.0.2\lib\dll_m32_n" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

[doublemax]

Does it only happen with the "display" sample? What about the "minimal" sample?

Also try building a debug version, maybe it gives more useful information when it crashes.

[stahta01]

FYI: I am trying to test using the TDM's Mingw 64 Bit compiler under windows 7 32 bit to see if the problem exists there.

I am trying this make command; note, I tried it once without the option -march=i686 and it had an issue; I think it was mixing 64bit code in the output.
I got a side by side error on running the program without the option -march=i686.

Note: The code is all on a single line; this website is not displaying it as such for me.

Code: Select all

mingw32-make -f makefile.gcc CFG="_m32" LDFLAGS="-march=i686 -m32" CPPFLAGS="-march=i686 -m32" CXXFLAGS="-std=gnu++11" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

My computer is slow so, it will be a few hours before the build completes.

Tim S.

[ChunJiu]

Does it only happen with the "display" sample? What about the "minimal" sample?

Also try building a debug version, maybe it gives more useful information when it crashes.

Thank you , the problem is appear in all 32bit applications compiled by TDM-GCC-64, even the official example is the same problem.

However, they do not use wxWidgets 3.0.2 will not be a problem.
For example, if you use wxWidgets 2.8.12, all applications are correct.

[ChunJiu]

FYI: I am trying to test using the TDM's Mingw 64 Bit compiler under windows 7 32 bit to see if the problem exists there.

I am trying this make command; note, I tried it once without the option -march=i686 and it had an issue; I think it was mixing 64bit code in the output.
I got a side by side error on running the program without the option -march=i686.

Note: The code is all on a single line; this website is not displaying it as such for me.

Code: Select all

mingw32-make -f makefile.gcc CFG="_m32" LDFLAGS="-march=i686 -m32" CPPFLAGS="-march=i686 -m32" CXXFLAGS="-std=gnu++11" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

My computer is slow so, it will be a few hours before the build completes.

Tim S.

Thank you very much, looking forward to your answer.

[stahta01]

I still got this message; so, it could be Compiler or wxWidgets 3.0.2 is doing something wrong.

I suggest using TDM's MinGW 32 Bit Compiler, instead.

The application has failed to start because its side-by-side configuration is in correct. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

I do NOT have any more time to try building today. If the CB Website works tomorrow I will look for the options I used to build Code::Blocks using TDM's MinGW64 GCC.

Tim S.

[ChunJiu]

I still got this message; so, it could be Compiler or wxWidgets 3.0.2 is doing something wrong.

I suggest using TDM's MinGW 32 Bit Compiler, instead.

The application has failed to start because its side-by-side configuration is in correct. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

I do NOT have any more time to try building today. If the CB Website works tomorrow I will look for the options I used to build Code::Blocks using TDM's MinGW64 GCC.

Tim S.

Okay, thanks.

I want to use a compiler instead two sets under the windows7 64bit, if not, can only use two sets of the compiler.

[eranon]

Hi All,
The TDM-GCC-64 compiled of 32bit code with the option -m32 under Windows64 will always be 0xc000007b error.

Hello. Does the provided manifest well indicates the targetted processor architecture for both the executable and the Windows Common Controls to use ?

[ChunJiu]

Hi All,
The TDM-GCC-64 compiled of 32bit code with the option -m32 under Windows64 will always be 0xc000007b error.

Hello. Does the provided manifest well indicates the targetted processor architecture for both the executable and the Windows Common Controls to use ?

Hello,

My computer configuration is as follows：

1. DELL 1950 1U Server - XEON 5405*2 , 24G RAM , Win7-64 Pro
2. Lenovo ThinkPad T500 - CPU T9800, 8G RAM , Win7-64 Ultimate

Because after experiencing problems, I need to verify, is to use the official's own example.
Subsequent generation of the error is the same...
So, no special Windows Common Controls.

[Manolo]

For 32 bits compilation using TDM 64 bits, try this:

Code: Select all

mingw32-make.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CXXFLAGS="-m32 -std=gnu++11 -fno-keep-inline-dllexport" CPP="gcc -E -D_M_IX86" LDFLAGS="-m32" CPPFLAGS="-m32" WINDRES="windres --use-temp-file -F pe-i386"

[ChunJiu]

For 32 bits compilation using TDM 64 bits, try this:

Code: Select all

mingw32-make.exe -j4 -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CXXFLAGS="-m32 -std=gnu++11 -fno-keep-inline-dllexport" CPP="gcc -E -D_M_IX86" LDFLAGS="-m32" CPPFLAGS="-m32" WINDRES="windres --use-temp-file -F pe-i386"

Thank you, I try to use your configuration again, this problem still exists.

So, I intend to formally report this bug.

[eranon]

Hi All,
The TDM-GCC-64 compiled of 32bit code with the option -m32 under Windows64 will always be 0xc000007b error.

Hello. Does the provided manifest well indicates the targetted processor architecture for both the executable and the Windows Common Controls to use ?

Hello,

My computer configuration is as follows：

1. DELL 1950 1U Server - XEON 5405*2 , 24G RAM , Win7-64 Pro
2. Lenovo ThinkPad T500 - CPU T9800, 8G RAM , Win7-64 Ultimate

Because after experiencing problems, I need to verify, is to use the official's own example.
Subsequent generation of the error is the same...
So, no special Windows Common Controls.

I meant how it goes if you explicitly embed a manifest in the final executable with mt.exe. A one like this, indicating the arch both for the exe itself and common controls :

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
  xmlns="urn:schemas-microsoft-com:asm.v1"
  manifestVersion="1.0">
<assemblyIdentity
    name="App x86"
    processorArchitecture="x86"
    version="1.0.0.0"
    type="win32"/>
<description>Executable</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

[ChunJiu]

I meant how it goes if you explicitly embed a manifest in the final executable with mt.exe. A one like this, indicating the arch both for the exe itself and common controls :

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
  xmlns="urn:schemas-microsoft-com:asm.v1"
  manifestVersion="1.0">
<assemblyIdentity
    name="App x86"
    processorArchitecture="x86"
    version="1.0.0.0"
    type="win32"/>
<description>Executable</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

Thank you, this is too much trouble. I need a relatively simple way, because recommend my friends to use wxWidgets.
So, i decided to use both 32/64 compilers.

[eranon]

As you want, Chun, but this quick test with manifest was not very hard to achieve. Maybe a useful link for reading : http://www.samlogic.net/articles/manifest.htm

Whatever be the compiler you'll use, without taking care of a manifest (which can be inside your final executable or beside, a simple XML file in the same directory), chance you'll get ugly controls at a point or another... But it's another subject