[Mingw-w64-public] Fails to build....
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt -m64 -D_SYSCRT=1 -DCRTDLL=1 -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/include -D_CRTBLD -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include -MT crt/lib64_libmingw32_a-gs_support.o -MD -MP -MF crt/.deps/lib64_libmingw32_a-gs_support.Tpo -c -o crt/lib64_libmingw32_a-gs_support.o `test -f 'crt/gs_support.c' || echo '/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/'`crt/gs_support.c /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:27: error: conflicting types for 'RtlLookupFunctionEntry' /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2375: note: previous declaration of 'RtlLookupFunctionEntry' was here /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:28: error: conflicting types for 'RtlVirtualUnwind' /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2413: note: previous declaration of 'RtlVirtualUnwind' was here Full log at http://launchpadlibrarian.net/55185586/buildlog_ubuntu-lucid-amd64.w64-toolchain_1.0b%2B201009080043-0w2176g93802b21973p11~lucid1_FAILEDTOBUILD.txt.gz Time 201009080043 Mingw-w64 trunk bzr 2176 = svn trunk 3526 Gcc 4.4 branch @ commit from ibolton (daily dump 20100908) Binutils daily dump @ 2010908 -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem configuringwxWidgets-2.9.1 withTDM64-GCC 4.5.1
John E wrote: I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single one-line patch under TDM64, and would not have released it if I couldn't. However, I always use makefile.gcc from the Windows shell, not MSYS. At any rate, the only way to prove to me that there is a TDM-GCC bug is with a single-file test case that should compile but does not. What does this have to do with strnlen? And I now have a successfully built copy of wxWidgets-2.9.1 built under MSYS ... dont know how considering I didnt actually change anything (except for copying the lib and include folders from C:\MinGW\x86_64-mingw32 to C:\MinGW and the one line patch that John E mentioned) ... why do I always gets these weird errors Regards Bidski -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fails to build....
2010/9/8 Dmitrijs Ledkovs dmitrij.led...@ubuntu.com: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt -m64 -D_SYSCRT=1 -DCRTDLL=1 -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/include -D_CRTBLD -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include -MT crt/lib64_libmingw32_a-gs_support.o -MD -MP -MF crt/.deps/lib64_libmingw32_a-gs_support.Tpo -c -o crt/lib64_libmingw32_a-gs_support.o `test -f 'crt/gs_support.c' || echo '/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/'`crt/gs_support.c /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:27: error: conflicting types for 'RtlLookupFunctionEntry' /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2375: note: previous declaration of 'RtlLookupFunctionEntry' was here /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:28: error: conflicting types for 'RtlVirtualUnwind' /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2413: note: previous declaration of 'RtlVirtualUnwind' was here Full log at http://launchpadlibrarian.net/55185586/buildlog_ubuntu-lucid-amd64.w64-toolchain_1.0b%2B201009080043-0w2176g93802b21973p11~lucid1_FAILEDTOBUILD.txt.gz Time 201009080043 Mingw-w64 trunk bzr 2176 = svn trunk 3526 Gcc 4.4 branch @ commit from ibolton (daily dump 20100908) Binutils daily dump @ 2010908 -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Issue fixed at revision 3529. Sorry, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libusb-win32 64bit device driver building with MinGW-w64
On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer seze...@gmail.com wrote: See http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/ I'd say take http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include/ddk/ from there and put it into its exclusive directory like c:\ddk or c:\mingw64\ddk or similar, and remove the one came with tdm64. And add this to your include path. Ok, I will try that. I get the svn ddk header and put it to src/ddk folder and modify the Makefile to point to it. Now I get tons of errors from winbase.h. There are many other errors, but the first one to solve seems to be winbase.h. gcc -c ./src/driver/abort_endpoint.c -o abort_endpoint.o -O2 -Wall -DWINVER=0x501 -DLOG_APPNAME=\libusb0-sys\ -DTARGETTYPE=DRIVER -I./src -I./src/driver -I./src/ddk -I. In file included from ./src/ddk/ntddk.h:38:0, from ./src/driver/libusb_driver.h:29, from ./src/driver/abort_endpoint.c:20: ./src/ddk/wdm.h:6669:36: warning: declaration does not declare anything In file included from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/windows.h:63:0, from ./src/usb.h:5, from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/usbdi.h:27, from ./src/driver/libusb_driver.h:31, from ./src/driver/abort_endpoint.c:20: d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:195:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:196:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PCRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:197:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LPCRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:198:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:199:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PCRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:200:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LPCRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1160:59: error: expected declaration specifiers or '...' before 'PMEMORY_BASIC_INFORMATION' In file included from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/windows.h:63:0, from ./src/usb.h:5, from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/usbdi.h:27, from ./src/driver/libusb_driver.h:31, from ./src/driver/abort_endpoint.c:20: d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1169:77: error: expected declaration specifiers or '...' before 'PMEMORY_BASIC_INFORMATION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1210:66: error: expected declaration specifiers or '...' before 'HEAP_INFORMATION_CLASS' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1211:68: error: expected declaration specifiers or '...' before 'HEAP_INFORMATION_CLASS' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1366:71: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1367:66: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1368:66: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1369:86: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1370:74: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1371:72: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1372:67: error:
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
On 9/8/2010 21:26, Sébastien Villemot wrote: Hi, Some extra information on the problem that I described in my previous post, and which I suspect to be a bug in MinGW-w64 for 64-bit platform. I attach a sample testcase, which I compile with: x86_64-w64-mingw32-gcc -g -O2 -fexceptions -Wall -shared -I~/MATLAB/extern/include mextest.c -o mextest.mexw64 -L~MATLAB/bin/win64 -lmex The libmex.dll contains both mexErrMsgTxt() and mexPrintf(). As such, the example makes MATLAB crash. But if I comment out the second function call (mexPrintf()), then the DLL behaves as expected: MATLAB catches the exception thrown by mexErrMsgTxt(), and displays the error message. It is very strangs since having or not the mexPrintf() should not change the result, since it is never reached. So it looks like a compiler bug, unless I’m missing something ? I’m not familiar with exception unwinding, so please forgive my ignorance. Any idea ? Best regards, Hi, sorry for the lack of responses, its hard to know what is wrong when nobody is familiar with Matlab internals. How exactly is a matlab exception thrown and caught anyway? -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
Hi, On 9/8/2010 21:26, Sébastien Villemot wrote: Hi, Some extra information on the problem that I described in my previous post, and which I suspect to be a bug in MinGW-w64 for 64-bit platform. I attach a sample testcase, which I compile with: x86_64-w64-mingw32-gcc -g -O2 -fexceptions -Wall -shared -I~/MATLAB/extern/include mextest.c -o mextest.mexw64 -L~MATLAB/bin/win64 -lmex The libmex.dll contains both mexErrMsgTxt() and mexPrintf(). As such, the example makes MATLAB crash. But if I comment out the second function call (mexPrintf()), then the DLL behaves as expected: MATLAB catches the exception thrown by mexErrMsgTxt(), and displays the error message. It is very strangs since having or not the mexPrintf() should not change the result, since it is never reached. So it looks like a compiler bug, unless Iâm missing something ? Iâm not familiar with exception unwinding, so please forgive my ignorance. Any idea ? Best regards, Hi, sorry for the lack of responses, its hard to know what is wrong when nobody is familiar with Matlab internals. How exactly is a matlab exception thrown and caught anyway? Please excuse my ignorance, I just read the subject and not the details but I would like to note that throwing/catching exceptions between DSO's (dynamically linked objects) can be very tricky with gcc, see http://gcc.gnu.org/wiki/Visibility esp. the Section Problems with C++ exceptions I couldn't get exceptions to work between DSO's _at_all_ when the exceptions where defined in a static library. So you might want to take a close look before using them. Hope this is useful, and if not, please forgive my ignorance! All the best, Mario -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
On Wed, Sep 08, 2010 at 11:22:20PM +0800, JonY wrote: On 9/8/2010 21:26, Sébastien Villemot wrote: Some extra information on the problem that I described in my previous post, and which I suspect to be a bug in MinGW-w64 for 64-bit platform. I attach a sample testcase, which I compile with: x86_64-w64-mingw32-gcc -g -O2 -fexceptions -Wall -shared -I~/MATLAB/extern/include mextest.c -o mextest.mexw64 -L~MATLAB/bin/win64 -lmex The libmex.dll contains both mexErrMsgTxt() and mexPrintf(). As such, the example makes MATLAB crash. But if I comment out the second function call (mexPrintf()), then the DLL behaves as expected: MATLAB catches the exception thrown by mexErrMsgTxt(), and displays the error message. It is very strangs since having or not the mexPrintf() should not change the result, since it is never reached. So it looks like a compiler bug, unless I’m missing something ? I’m not familiar with exception unwinding, so please forgive my ignorance. sorry for the lack of responses, its hard to know what is wrong when nobody is familiar with Matlab internals. Thanks for your answer. I perfectly understand that it is difficult for you to give any help in this context. How exactly is a matlab exception thrown and caught anyway? Unfortunately I have no idea, this is not documented. In this case the exception is thrown by a MATLAB internal, and catched by another internal. Attached is a WinDbg log of the crash. One can see my module (mextest.mexw64) loaded, then the exception being thrown and then a stack overflow. Hope this helps. Note that I also tried with gdb (TDM build) but the results did not look useful. If there is any extra information that I could provide to help debug this, in particular through any debugger (gdb or WinDbg), please let me know. Thanks, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/) *** wait with pending attach Symbol search path is: *** Invalid *** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * Executable search path is: ModLoad: `0040 `004d3000 C:\Program Files\MATLAB\R2007a\bin\win64\MATLAB.exe ModLoad: `77ec `77ffb000 C:\WINDOWS\system32\ntdll.dll ModLoad: `77d4 `77eb3000 C:\WINDOWS\system32\kernel32.dll ModLoad: `1000 `103f5000 C:\Program Files\MATLAB\R2007a\bin\win64\libut.dll ModLoad: `4a90 `4aa01000 C:\Program Files\MATLAB\R2007a\bin\win64\icuin32.dll ModLoad: `4a80 `4a8dd000 C:\Program Files\MATLAB\R2007a\bin\win64\icuuc32.dll ModLoad: 07ff`7fee 07ff`7ffe6000 C:\WINDOWS\system32\ADVAPI32.dll ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll ModLoad: `0026 `00267000 C:\Program Files\MATLAB\R2007a\bin\win64\icudt32.dll ModLoad: `7813 `781f9000 C:\WINDOWS\WinSxS\amd64_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_18A05F69\MSVCR80.dll ModLoad: 07ff`7fc0 07ff`7fc86000 C:\WINDOWS\system32\msvcrt.dll ModLoad: `4ab0 `4ab1 C:\Program Files\MATLAB\R2007a\bin\win64\icuio32.dll ModLoad: `7c42 `7c529000 C:\WINDOWS\WinSxS\amd64_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_18A05F69\MSVCP80.dll ModLoad: 07ff`7e47 07ff`7e483000 C:\WINDOWS\system32\imagehlp.dll ModLoad: `77c2 `77d2c000 C:\WINDOWS\system32\USER32.dll ModLoad: 07ff`7fc9 07ff`7fd2c000 C:\WINDOWS\system32\GDI32.dll ModLoad: `0029 `002e2000 C:\Program Files\MATLAB\R2007a\bin\win64\mcr.dll ModLoad: 07ff`7f19 07ff`7fb9c000 C:\WINDOWS\system32\SHELL32.dll ModLoad: 07ff`7ef6 07ff`7effb000 C:\WINDOWS\system32\SHLWAPI.dll ModLoad: 07ff`5714 07ff`573c5000 C:\WINDOWS\system32\ole32.dll ModLoad: `0030 `00356000 C:\Program Files\MATLAB\R2007a\bin\win64\jmi.dll ModLoad: 07ff`770f 07ff`770fa000 C:\WINDOWS\system32\WSOCK32.dll ModLoad: 07ff`7731 07ff`7734 C:\WINDOWS\system32\WS2_32.dll ModLoad: 07ff`7714 07ff`7714c000 C:\WINDOWS\system32\WS2HELP.dll ModLoad: `0037 `003db000 C:\Program Files\MATLAB\R2007a\bin\win64\libmx.dll ModLoad: `00ce `00cf2000 C:\Program Files\MATLAB\R2007a\bin\win64\libz.dll ModLoad:
Re: [Mingw-w64-public] libusb-win32 64bit device driver building with MinGW-w64
On Wed, Sep 8, 2010 at 5:12 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer seze...@gmail.com wrote: See http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/ I'd say take http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include/ddk/ from there and put it into its exclusive directory like c:\ddk or c:\mingw64\ddk or similar, and remove the one came with tdm64. And add this to your include path. Ok, I will try that. I get the svn ddk header and put it to src/ddk folder and modify the Makefile to point to it. Now I get tons of errors from winbase.h. There are many other errors, but the first one to solve seems to be winbase.h. gcc -c ./src/driver/abort_endpoint.c -o abort_endpoint.o -O2 -Wall -DWINVER=0x501 -DLOG_APPNAME=\libusb0-sys\ -DTARGETTYPE=DRIVER -I./src -I./src/driver -I./src/ddk -I. In file included from ./src/ddk/ntddk.h:38:0, from ./src/driver/libusb_driver.h:29, from ./src/driver/abort_endpoint.c:20: ./src/ddk/wdm.h:6669:36: warning: declaration does not declare anything In file included from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/windows.h:63:0, from ./src/usb.h:5, from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/usbdi.h:27, from ./src/driver/libusb_driver.h:31, from ./src/driver/abort_endpoint.c:20: d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:195:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:196:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PCRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:197:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LPCRITICAL_SECTION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:198:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'CRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:199:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PCRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:200:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LPCRITICAL_SECTION_DEBUG' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1160:59: error: expected declaration specifiers or '...' before 'PMEMORY_BASIC_INFORMATION' In file included from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/windows.h:63:0, from ./src/usb.h:5, from d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/usbdi.h:27, from ./src/driver/libusb_driver.h:31, from ./src/driver/abort_endpoint.c:20: d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1169:77: error: expected declaration specifiers or '...' before 'PMEMORY_BASIC_INFORMATION' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1210:66: error: expected declaration specifiers or '...' before 'HEAP_INFORMATION_CLASS' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1211:68: error: expected declaration specifiers or '...' before 'HEAP_INFORMATION_CLASS' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1366:71: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1367:66: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1368:66: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1369:86: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1370:74: error: expected ')' before 'lpCriticalSection' d:\tdm\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winbase.h:1371:72: error: expected ')' before
Re: [Mingw-w64-public] Canadian cross still broken?
Hi JonY, On 09/07/2010 12:03 PM, JonY wrote: On 9/7/2010 15:20, Mario Emmenlauer wrote: On 9/7/2010 01:34, Mario Emmenlauer wrote: On 09/06/2010 04:52 PM, JonY wrote: On 9/6/2010 19:50, Mario Emmenlauer wrote: On 9/6/2010 15:52, Mario Emmenlauer wrote: I'm the original author of the issue [0] that Ismail referenced. During the last months since my report, I've repeatedly re-tried numerous times, but failed to build the canadian cross. Actually, back then mostly the same suggestions where given, tried, and failed. As you can see from my post, I've tried the following compile instructions: - makefile: mingw64 svn experimental/buildsystem/makebuildroot-test.mk - makefile: mingw64 svn experimental/buildsystem/makebuildroot.mk - compile instructions from mingw64 sourceforge wiki all with variations of multilib, gcc-versions, ld-versions etc... Would it maybe be a good idea that someone who got the canadian cross running create a working Makefile? There are the excellent Makefiles makebuildroot-test.mk and makebuildroot.mk (from your project), that both follow the wiki compile instructions (more or less), but both fail in the pre-last step of ld linking. A working Makefile would be a good documentation, reference, and a perfect standard for regression testing. [0] http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00839.html Did you link lib to lib64? And do you have lib32? Native cross-back works fine for me. As I wrote above, I tried amongst many other things your (unmodified) makefile makebuildroot-test.mk, so yes lib was linked to lib64. Are you talking about a triple cross? I tried i686-linux-sparc-linux-mingw64 before, it works fine too. You might have better chance with makebuildroot-test.mk for canadian cross, I've used it for the sparc triple cross. Hmm not sure I follow here. Have you a running canadian cross fro mingw-w64 on Linux? As I wrote above, I have tried the suggested makebuildroot-test.mk for canadian cross, and it fails with the described error: make all-target-libgcc, message is: [cut]/build/root/x86_64-w64-mingw32/bin/ld: skipping incompatible \ [cut]/build/root/mingw/lib/libmingw32.a when searching for -lmingw32 Which revision of the makefile have you tested? Those are actually warnings, ld will continue to walk through the directories. Can you post the last command and all of its errors/warnings? You are right, I posted the warnings only, sorry:( The error is that ld fails to find a compatible libmingw32. I don't have the log here right now, but can produce it if you like? Here a bit more information from my original post [0]: There are more identical errors for other libs like kernel32 and msvcrt. objdump lists the correct format: [cut]/build/root/bin/x86_64-w64-mingw32-objdump --archive-headers \ [cut]/build/root/x86_64-w64-mingw32/lib/libmingw32.a [...] lib64_libmingw32_a-tlsmcrt.o: file format pe-x86-64 Also, ld seems to be valid: [cut]/build/root/bin/x86_64-w64-mingw32-ld: supported targets: \ pe-x86-64 pei-x86-64 elf64-x86-64 elf64-l1om elf64-little elf64-big \ elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex I suspect it was scanning for 32bit objects. 32bit support also seems to be missing in ld. Check the makefile if you've enabled multilib options. I have tried it about ten times repeatedly with and without multilib, and every time started from scratch (removing all sources and binaries). I have redirected all output to a logfile and checked that the switches for enabling or disabling multilib where indeed used, so I'm sure there was no error in that part. BTW, I once messed up the multilib switches, then it did not even compile until the second run, it failed in the first bootstrapping of gcc. Now it fails in the second run, final step when it should link gcc. This is very strange, can you attach the build logs, including the command used to invoke the makefile? Here is the logfile: http://data.marssoft.de/makebuildroot-test.mk-log20100907a.txt.lzma I used the following changes and/or versions of packages (note esp. the gcc-4.5.1 and pthreads from 2010-02-28): GMP_VERSION ?= 5.0.1 MPFR_VERSION ?= 3.0.0 MPC_VERSION ?= 0.8.2 PPL_VERSION ?= 0.10.2 CLOOG_VERSION ?= 0.15.9 MINGW_BRANCH ?= trunk MINGW_REVISION ?= HEAD GCC_BRANCH ?= tags/gcc_4_5_1_release PTHREADS_CVS_CO_ARGS ?= -D 2010-02-28 MAKE_OPTS ?= -j4 The logfile is complete, starting with unpacking the updated source tree and ending with ld failing to link. Other than the options shown above I did not modify anything, except for adding the pthreads checkout revision to the CVS command. All the best, Mario -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
On Thu, Sep 9, 2010 at 4:25 AM, JonY jo...@users.sourceforge.net wrote: On 9/8/2010 23:34, Mario Emmenlauer wrote: Please excuse my ignorance, I just read the subject and not the details but I would like to note that throwing/catching exceptions between DSO's (dynamically linked objects) can be very tricky with gcc, see http://gcc.gnu.org/wiki/Visibility esp. the Section Problems with C++ exceptions I couldn't get exceptions to work between DSO's _at_all_ when the exceptions where defined in a static library. So you might want to take a close look before using them. Hope this is useful, and if not, please forgive my ignorance! OP says the DLL is C code. Exception doesn't automatically mean C++. umm, Mario may be on the right track. Does mexPrintf() use C++ string class? If so, and you are using auto-import to link in libstdc++.dll, then the problems described at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612, may bite. Unless libstdc++ basic_string class is marked as dllimport, _S_empty_rep is effectively hidden and different modules will have different addresses for _S_empty_rep. This can be fised by compiling libstdc++ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
may bite. Unless libstdc++ basic_string class is marked as dllimport, _S_empty_rep is effectively hidden and different modules will have different addresses for _S_empty_rep. fat fingers This can be fised by compiling libstdc++ fat fingers/ This can be fixed by compiling libstdc++ with --enable-fully-dynamic-string. Danny -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libusb-win32 64bit device driver building with MinGW-w64
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer seze...@gmail.com wrote: I made some progress: I checked out branches/libusb-testing/ from your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c and it succeeded with the following changes: 1. one thing causing the mess was the windows.h include in your own src/usb.h: including windef.h is enough. Including windows.h along with ddk-only headers will pull in winbase.h and the errors you just saw will show up. AFAIK, windows.h should be avoided unless really necessary. You should scan your other sources for it 2. the name of your src/usb.h is, well, usb.h, and it conflicts, ie. searched before the system provided usb.h. Therefore, it must be renamed to something else. For my own tests, I renamed it to usb_private.h and changed all occurences of #include usb.h (with quotes) to use the new name. 3. I had to change the order of includes in src/driver/libusb_driver.h to look like the following: #ifdef __GNUC__ #include ddk/ntddk.h #if !defined(DDKAPI) #define DDKAPI NTAPI #endif #include usbdi.h #include usbdlib_gcc.h #else ... Note that there is no DDKAPI definition anywhere in the DDK: it only appears in the mingw.org version of headers and it is ancient. New code must use NTAPI (I used the above ifndef above just out of laziness.) 4. To avoid the redeclarations, I changed the ifdef in libusb_driver.h to look like /* some missing defines */ #if defined(__GNUC__) !defined(__MINGW64_VERSION_MAJOR) (because I don't know whether mingw.org have them.) After doing these, I get: $ x86_64-w64-mingw32-gcc -c ./src/driver/abort_endpoint.c -o abort_endpoint.o -O2 -Wall -DWINVER=0x501 -DLOG_APPNAME=\libusb0-sys\ -DTARGETTYPE=DRIVER -I./src -I./src/driver -I/home/ozzie/Download/ddk_test/include -I/home/ozzie/Download/ddk_test/include/ddk -I. In file included from /home/ozzie/Download/ddk_test/include/ddk/ntddk.h:38, from ./src/driver/libusb_driver.h:28, from ./src/driver/abort_endpoint.c:20: /home/ozzie/Download/ddk_test/include/ddk/wdm.h:6669: warning: declaration does not declare anything That warning from wdm.h is just normal. You can avoid it, too, if you use -fms-extensions. Hope these help. Wow this is great help. I will try your suggestions on other files. Thanks a lot! -- Xiaofan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 packaging problem or libtool problem
On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:36 AM, JonY jo...@users.sourceforge.net wrote: Ok, to clear everything up, for non-multilib 4.6, you should only have lib, lib64 only if you have non-multilib 4.5. It seems the latest automatic build version still has the same issue as previous versions, I just checked the following one. It has the same non-linked lib64 directory with a few files, same issue as the previous mingw-w64-1.0-bin_i686-mingw_20100702.zip and private build mingw-w64-bin_i686-mingw_20100711_sezero.zip. In this case, I will have issues to build libusb-1.0 Windows backend. The problem is that in this case, the generated libtool script seems to want to use lib64. # Compile-time system search path for libraries. sys_lib_search_path_spec=d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc/x86_64-w64-mingw32/4.5.2 d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/x86_64-w64-mingw32/lib64 D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906bin\x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=bin\x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/ build/root --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj-c++ --enable-fully-dyna mic-string --disable-multilib Thread model: win32 gcc version 4.5.2 20100906 (prerelease) (GCC) You can see that it has disabled multilib. D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906dir x86_64-w64-mingw32 /w [.] [..] .mkdir.marker [bin] [include] [lib] [lib32] [lib64] D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906dir x86_64-w64-mingw32\lib64 /w [.] [..] libgcc_s.dll.a libgfortran.a libgfortran.dll.a libgfortran.la libiberty.a libobjc.a libobjc.dll.a libobjc.la libssp.a libssp.dll.a libssp.la libssp_nonshared.a libssp_nonshared.la libstdc++.a libstdc++.dll.a libstdc++.dll.a-gdb.py libstdc++.la libsupc++.a libsupc++.la Can this be fixed and lib64 directory be removed? Another thing, typically other MinGW-w64 binaries for WIndows will have gcc along with x86_64-w64-mingw32-gcc.exe and other similar links. But the automatic build does not have that. One good thing is that mingw_i686 version is now provided (mingw-w64-1.0-bin_i686-mingw_20100906.zip). Thanks. Just wondering if it is better to have a 64bit Windows build as well (like http://www.drangon.org/mingw/ ). 64bit Linux build is provided along with 32bit Linux. -- Xiaofan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] 64-bit reimp?
Hi All, I'm trying to create a python enabled gdb for 64-bit MinGW-w64. Unfortunately the x64 python distribution for Windows does not include a libpython27.a and as such I was hoping to create one from the python27.lib file it does supply. Normally I'd use reimp in the mingw.org world, but can't find reimp for mingw-w64. Is there reimp available, or a tool that provides similar functionality? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Canadian cross still broken?
On 9/9/2010 04:27, Mario Emmenlauer wrote: Hi JonY, On 09/07/2010 12:03 PM, JonY wrote: On 9/7/2010 15:20, Mario Emmenlauer wrote: On 9/7/2010 01:34, Mario Emmenlauer wrote: On 09/06/2010 04:52 PM, JonY wrote: On 9/6/2010 19:50, Mario Emmenlauer wrote: On 9/6/2010 15:52, Mario Emmenlauer wrote: I'm the original author of the issue [0] that Ismail referenced. During the last months since my report, I've repeatedly re-tried numerous times, but failed to build the canadian cross. Actually, back then mostly the same suggestions where given, tried, and failed. As you can see from my post, I've tried the following compile instructions: - makefile: mingw64 svn experimental/buildsystem/makebuildroot-test.mk - makefile: mingw64 svn experimental/buildsystem/makebuildroot.mk - compile instructions from mingw64 sourceforge wiki all with variations of multilib, gcc-versions, ld-versions etc... Would it maybe be a good idea that someone who got the canadian cross running create a working Makefile? There are the excellent Makefiles makebuildroot-test.mk and makebuildroot.mk (from your project), that both follow the wiki compile instructions (more or less), but both fail in the pre-last step of ld linking. A working Makefile would be a good documentation, reference, and a perfect standard for regression testing. [0] http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00839.html Did you link lib to lib64? And do you have lib32? Native cross-back works fine for me. As I wrote above, I tried amongst many other things your (unmodified) makefile makebuildroot-test.mk, so yes lib was linked to lib64. Are you talking about a triple cross? I tried i686-linux-sparc-linux-mingw64 before, it works fine too. You might have better chance with makebuildroot-test.mk for canadian cross, I've used it for the sparc triple cross. Hmm not sure I follow here. Have you a running canadian cross fro mingw-w64 on Linux? As I wrote above, I have tried the suggested makebuildroot-test.mk for canadian cross, and it fails with the described error: make all-target-libgcc, message is: [cut]/build/root/x86_64-w64-mingw32/bin/ld: skipping incompatible \ [cut]/build/root/mingw/lib/libmingw32.a when searching for -lmingw32 Which revision of the makefile have you tested? Those are actually warnings, ld will continue to walk through the directories. Can you post the last command and all of its errors/warnings? You are right, I posted the warnings only, sorry:( The error is that ld fails to find a compatible libmingw32. I don't have the log here right now, but can produce it if you like? Here a bit more information from my original post [0]: There are more identical errors for other libs like kernel32 and msvcrt. objdump lists the correct format: [cut]/build/root/bin/x86_64-w64-mingw32-objdump --archive-headers \ [cut]/build/root/x86_64-w64-mingw32/lib/libmingw32.a [...] lib64_libmingw32_a-tlsmcrt.o: file format pe-x86-64 Also, ld seems to be valid: [cut]/build/root/bin/x86_64-w64-mingw32-ld: supported targets: \ pe-x86-64 pei-x86-64 elf64-x86-64 elf64-l1om elf64-little elf64-big \ elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex I suspect it was scanning for 32bit objects. 32bit support also seems to be missing in ld. Check the makefile if you've enabled multilib options. I have tried it about ten times repeatedly with and without multilib, and every time started from scratch (removing all sources and binaries). I have redirected all output to a logfile and checked that the switches for enabling or disabling multilib where indeed used, so I'm sure there was no error in that part. BTW, I once messed up the multilib switches, then it did not even compile until the second run, it failed in the first bootstrapping of gcc. Now it fails in the second run, final step when it should link gcc. This is very strange, can you attach the build logs, including the command used to invoke the makefile? Here is the logfile: http://data.marssoft.de/makebuildroot-test.mk-log20100907a.txt.lzma I used the following changes and/or versions of packages (note esp. the gcc-4.5.1 and pthreads from 2010-02-28): GMP_VERSION ?= 5.0.1 MPFR_VERSION ?= 3.0.0 MPC_VERSION ?= 0.8.2 PPL_VERSION ?= 0.10.2 CLOOG_VERSION ?= 0.15.9 MINGW_BRANCH ?= trunk MINGW_REVISION ?= HEAD GCC_BRANCH ?= tags/gcc_4_5_1_release PTHREADS_CVS_CO_ARGS ?= -D 2010-02-28 MAKE_OPTS ?= -j4 The logfile is complete, starting with unpacking the updated source tree and ending with ld failing to link. Other than the options shown above I did not modify anything, except for adding the pthreads checkout revision to the CVS command. All the best, Mario Something is not right about the logs. GCC was built with --disable-multilib, but the
Re: [Mingw-w64-public] Cross-DLL exception on 64-bit
On 9/9/2010 06:14, Danny Smith wrote: may bite. Unless libstdc++ basic_string class is marked as dllimport, _S_empty_rep is effectively hidden and different modules will have different addresses for _S_empty_rep. fat fingers This can be fised by compiling libstdc++ fat fingers/ This can be fixed by compiling libstdc++ with --enable-fully-dynamic-string. Danny Well, mingw-w64 autobuilds do use that option. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 packaging problem or libtool problem
On 9/9/2010 08:00, Xiaofan Chen wrote: On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:36 AM, JonYjo...@users.sourceforge.net wrote: Ok, to clear everything up, for non-multilib 4.6, you should only have lib, lib64 only if you have non-multilib 4.5. It seems the latest automatic build version still has the same issue as previous versions, I just checked the following one. It has the same non-linked lib64 directory with a few files, same issue as the previous mingw-w64-1.0-bin_i686-mingw_20100702.zip and private build mingw-w64-bin_i686-mingw_20100711_sezero.zip. In this case, I will have issues to build libusb-1.0 Windows backend. The problem is that in this case, the generated libtool script seems to want to use lib64. # Compile-time system search path for libraries. sys_lib_search_path_spec=d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc/x86_64-w64-mingw32/4.5.2 d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/x86_64-w64-mingw32/lib64 D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906bin\x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=bin\x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/ build/root --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj-c++ --enable-fully-dyna mic-string --disable-multilib Thread model: win32 gcc version 4.5.2 20100906 (prerelease) (GCC) You can see that it has disabled multilib. D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906dir x86_64-w64-mingw32 /w [.] [..].mkdir.marker [bin] [include] [lib] [lib32] [lib64] D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906dir x86_64-w64-mingw32\lib64 /w [.] [..] libgcc_s.dll.a libgfortran.alibgfortran.dll.a libgfortran.la libiberty.a libobjc.a libobjc.dll.alibobjc.la libssp.a libssp.dll.a libssp.la libssp_nonshared.a libssp_nonshared.la libstdc++.a libstdc++.dll.a libstdc++.dll.a-gdb.py libstdc++.la libsupc++.a libsupc++.la Can this be fixed and lib64 directory be removed? If you have moved them and lib64 becomes empty, yes. Another thing, typically other MinGW-w64 binaries for WIndows will have gcc along with x86_64-w64-mingw32-gcc.exe and other similar links. But the automatic build does not have that. You should not be using gcc, but x86_64-w64-mingw32-gcc instead. It is a cross compiler. One good thing is that mingw_i686 version is now provided (mingw-w64-1.0-bin_i686-mingw_20100906.zip). Thanks. Just wondering if it is better to have a 64bit Windows build as well (like http://www.drangon.org/mingw/ ). 64bit Linux build is provided along with 32bit Linux. I don't know about 64bit windows builds, but there is no benefit from using 64bit compilers, unless you need more than 4GB to process your sources. Its a low priority for now, we really lack manpower. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 packaging problem or libtool problem
On Thu, Sep 9, 2010 at 11:11 AM, JonY jo...@users.sourceforge.net wrote: Can this be fixed and lib64 directory be removed? If you have moved them and lib64 becomes empty, yes. Move them to lib, right? What are the use of those files? Another thing, typically other MinGW-w64 binaries for Windows will have gcc along with x86_64-w64-mingw32-gcc.exe and other similar links. But the automatic build does not have that. You should not be using gcc, but x86_64-w64-mingw32-gcc instead. It is a cross compiler. I see. This makes sense. However, TDM64 does use gcc, under 32bit or 64bit Windows. I think it is a cross-compiler as well. One good thing is that mingw_i686 version is now provided (mingw-w64-1.0-bin_i686-mingw_20100906.zip). Thanks. Just wondering if it is better to have a 64bit Windows build as well (like http://www.drangon.org/mingw/ ). 64bit Linux build is provided along with 32bit Linux. I don't know about 64bit windows builds, but there is no benefit from using 64bit compilers, unless you need more than 4GB to process your sources. Its a low priority for now, we really lack manpower. No problem. I am just wondering about why there is a 64bit Linux build but no 64bit Windows build. I use both Windows and Linux, MinGW and Cygwin. But I just think Windows should have higher priority than Linux for MinGW-w64. Now I understand the situation. It is not a real problem. -- Xiaofan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW-w64 packaging problem or libtool problem
On 9/8/2010 9:43 PM, Xiaofan Chen wrote: I see. This makes sense. However, TDM64 does use gcc, under 32bit or 64bit Windows. I think it is a cross-compiler as well. No, TDM64 GCC is a native x86_64-w64-mingw32 compiler -- in other words, it runs under Windows 64-bit and targets (by default) Windows 64-bit. (You can pretty much ignore the fact that GCC's own executables just happen to be compiled with -m32 to allow it to also run under Windows 32-bit, unless you're compiling such huge amounts of code as to require more than 2GB of memory during compilation.) -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Canadian cross still broken?
cd gcc-4.5.1-build ln -s /mypath/x86_64-w64-mingw32 ./mingw assuming, that you are building/configuring gcc in the folder gcc-4.5.1-build - otherwise whatever path I guess the howto assumes that /mypath is also the configure and build directory, than you do not have that problem, but if your build/configure directory is somewhere totally else, than gcc does not know here to find the mingw folder make and make install runs smoothly afterwards!! No, the symlink is done after install, you shouldn't be doing any symlinks during build time, unless I am misunderstanding something. I am not sure, what is right, but this is what the howto says: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/branches/releases/v1.0/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt?revision=3506view=markup line 230 and following: 230 Step 3) GCC requires the x86_64-w64-mingw32 directory be mirrored as a 231 directory 'mingw' in the same root. So, if using configure default 232 /usr/local, type: 233 ln -s /usr/local/x86_64-w64-mingw32 /usr/local/mingw 234 or, for sysroot, type: 235 ln -s /mypath/x86_64-w64-mingw32 /mypath/mingw 236 237 Step 4) Manually create the x86_64-w64-mingw32/lib directory: 238 mkdir -p /usr/local/x86_64-w64-mingw32/lib 239 or, for sysroot: 240 mkdir -p /mypath/x86_64-w64-mingw32/lib 241 If it already exists and you get an error, ignore it. 242 243 Step 5) Symlink x86_64-w64-mingw32/lib directory as x86_64-w64-mingw32/lib64: 244 ln -s /usr/local/x86_64-w64-mingw32/lib /usr/local/x86_64-w64-mingw32/lib64 245 or, for sysroot: 246 ln -s /mypath/x86_64-w64-mingw32/lib /mypath/x86_64-w64-mingw32/lib64 After make install, the last thing I did was, to make symlinks in sysroot or prefix ln -s /mypath/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a /mypath/x86_64-w64-mingw32/lib32/ and ln -s /mypath/lib/gcc/x86_64-w64-mingw32/lib64/libgcc_s.a /mypath/x86_64-w64-mingw32/lib64/ compiler and linker works (at least -m32, I have not tried the 64bit) This is a known issue when --enable-runtime-specific-libs is used, happens in Linux as well. I did configure with --enable-runtime-specific-libs so this makes sense - I was not aware that would be the consequence.. There are only warnings, but ultimately, the error is: /blue/meilerlab/apps/Linux2/x86_64/mingw-w64/2010.09.07/x86_64-w64-mingw32/bin/ld: cannot find -lmingw32 the same for: -lmingwex, -lmoldname, -lmsvcrt, -luser32, -lkernel32, -ladvapi32, -lshell32 This does not occur for me. Perhaps you want to try --with-build-sysroot. I tried building binutils and gcc with --with-build-sysroot, and the stage 2 gcc will fail with that error: The directory that should contain system headers does not exist: yes/mingw/include so I assume, that I have to specifically pass the sysroot, that I also passed to --with-build-sysroot=/mypath but when I do this for binutils and gcc I get this error: float.h .. error: #error Corrupt install of gcc's internal headers, or search order was changed. There is something I still do not understand. The problem is, xgcc does not know about the lib32 mypath - when calling /blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/./gcc/xgcc -m32 --print-search-dirs this is the output libraries: =/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/../lib32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/../lib32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/g cc-4.5.1/gcc/../lib/gcc/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/ it only list the builddir subfolders of:
Re: [Mingw-w64-public] MinGW-w64 packaging problem or libtool problem
On Thu, Sep 9, 2010 at 12:09 PM, John E. / TDM tdra...@tdragon.net wrote: On 9/8/2010 9:43 PM, Xiaofan Chen wrote: I see. This makes sense. However, TDM64 does use gcc, under 32bit or 64bit Windows. I think it is a cross-compiler as well. No, TDM64 GCC is a native x86_64-w64-mingw32 compiler -- in other words, it runs under Windows 64-bit and targets (by default) Windows 64-bit. Thanks for the clarification. I now understand that it is a native 64bit compiler under 64bit Windows. (You can pretty much ignore the fact that GCC's own executables just happen to be compiled with -m32 to allow it to also run under Windows 32-bit, ) That is the confusing part. I think in this case it is a cross-compiler under 32bit Windows-- it is producing 64bit binary which does not run under 32bit Windows. -- Xiaofan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
