-
I also met with this issue.
I use the latest toolchain to cross compile ffmpeg, the produced 32bit ffmpeg.exe runs fine under WinXP x64, but runs blocked under 32bit WinXP.
But my application that using wxWidgets library runs fine in both OS.
2009-11-14 02:05:07 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
no, it doesn't work.
a very simple source t1.cpp :
------------------------
ifdef __cplusplus
extern "C" {
#endif
#include
#ifdef __cplusplus
}
#endif
int main( int argc, char * argv[] )
{
return -1;
}
----------------------------
compile as C program works, but compile as C++ failed. compile as C++ and without extern "C" also failed.
[drangon@dgnfedora test]$...
2009-08-28 12:25:02 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
I use the trunk to build a cross compiler, then use this compiler to build wxWidgets, the following error :
/compile/mingw-w64-dgn/lib_build/bd_wxWidgets/bk-make-pch ./.pch/wxprec_basedll/wx/wxprec.h.gch wx/wxprec.h x86_64-w64-mingw32-g++ -I./.pch/wxprec_basedll -D__WXMSW__ -I/compile/mingw-w64-dgn/lib_source/wxWidgets/src/tiff -I/compile/mingw-w64-dgn/lib_source/wxWidgets/src/jpeg...
2009-08-28 11:04:30 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
I cross compile the x86_64-w64-mingw32 under linux x86_64 platform, the build ffmpeg, and wxWidgets, and application using wxWidgets and ffmpeg.
ffmpeg built with -O3, read data success, but when call write frame function, the program crashed. the AVFormatContext pointer value is 1, not a valid pointer.
wxWidgets built with -O0, simple application using wxWidgets compiles and runs well...
2009-08-11 14:46:16 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
x86_64-*-mingw32-g++ is broken, it seems to be the problem of libgcc_s_sjlj-1.dll.
I replace libgcc_s_sjlj-1.dll with a version of 2009-06-20, Then it runs ok.
I compare the source code between 2009-06-20 to 2009-07-20, does not find any obvious
problem. The diff is small, maybe it is worth to dig into it.
BTW, do you modify gmp 4.3.1 ? I encounter the following problem when build gmp...
2009-07-26 02:11:23 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
adding flag "--disable-libstdcxx-pch" when configure gcc can bypass this.
and there are another bug make native c++ program crashed, see the following :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39832.
2009-07-22 12:31:00 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
I try the latest code from SVN (20090423), this problem no longer exist. The application runs well.
2009-04-23 15:55:28 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
Yes, I use all the latest code from SVN, which is version 4.5 for gcc.
I try the latest code today, the problem still exist.
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../gcc/configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mi
ngw32 --disable-nls --enable-languages=c,c++ --with-gmp=/compile/mingw/for_targe
t --enable-twoprocess --disable-libstdcxx-pch...
2009-04-21 05:13:54 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
I built a toolchain from scratch with the newest code from SVN ( 20090411 ).
and the build an application using wxWidgets llibrary, it runs crashed.
(gdb) r
Starting program: E:\code\DMediaInfo/DMediaInfo.exe
[New Thread 2656.0xbd8]
warning: Can not parse XML library list; XML support was disabled at compile tim
e
[New Thread 2656.0x964]
Program received signal SIGSEGV, Segmentation...
2009-04-12 13:28:59 UTC in MinGW-w64 - for 32 and 64 bit Windows
-
.file "eh_alloc.cc"
.text
.def _ptrdiff_t; .scl 13; .type 05; .endef
.def _size_t; .scl 13; .type 017; .endef
.def ___int128; .scl 13; .type 00; .endef
.def _uintptr_t; .scl 13; .type 017; .endef
.def ___gnuc_va_list; .scl 13; .type 02.
2008-01-08 10:31:05 UTC in MinGW-w64 - for 32 and 64 bit Windows
