From: Sisyphus <sis...@op...> - 2008-05-18 06:43:06
|
Hi, C:\>type try.c #include <windows.h> int main(void) { return 1; } C:\>gcc -o try.exe try.c In file included from C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h:44, from C:\_64\mingw64\x86_64-pc-mingw32\include/emmintrin.h:43, from C:\_64\mingw64\x86_64-pc-mingw32\include/intrin.h:13, from C:\_64\mingw64\x86_64-pc-mingw32\include/winnt.h:1149, from C:\_64\mingw64\x86_64-pc-mingw32\include/windef.h:122, from C:\_64\mingw64\x86_64-pc-mingw32\include/windows.h:62, from try.c:1: C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_add_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:317: error: incompatible type for argument 1 of '__builtin_ia32_paddq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:317: error: incompatible type for argument 2 of '__builtin_ia32_paddq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sub_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:421: error: incompatible type for argument 1 of '__builtin_ia32_psubq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:421: error: incompatible type for argument 2 of '__builtin_ia32_psubq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sll_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:528: error: incompatible type for argument 2 of '__builtin_ia32_psllw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_slli_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:540: error: incompatible type for argument 2 of '__builtin_ia32_psllw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sll_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:553: error: incompatible type for argument 2 of '__builtin_ia32_pslld' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_slli_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:565: error: incompatible type for argument 2 of '__builtin_ia32_pslld' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sll_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:578: error: incompatible type for argument 1 of '__builtin_ia32_psllq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:578: error: incompatible type for argument 2 of '__builtin_ia32_psllq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_slli_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:590: error: incompatible type for argument 1 of '__builtin_ia32_psllq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:590: error: incompatible type for argument 2 of '__builtin_ia32_psllq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sra_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:603: error: incompatible type for argument 2 of '__builtin_ia32_psraw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srai_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:615: error: incompatible type for argument 2 of '__builtin_ia32_psraw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_sra_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:628: error: incompatible type for argument 2 of '__builtin_ia32_psrad' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srai_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:640: error: incompatible type for argument 2 of '__builtin_ia32_psrad' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srl_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:653: error: incompatible type for argument 2 of '__builtin_ia32_psrlw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srli_pi16': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:665: error: incompatible type for argument 2 of '__builtin_ia32_psrlw' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srl_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:678: error: incompatible type for argument 2 of '__builtin_ia32_psrld' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srli_pi32': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:690: error: incompatible type for argument 2 of '__builtin_ia32_psrld' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srl_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:703: error: incompatible type for argument 1 of '__builtin_ia32_psrlq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:703: error: incompatible type for argument 2 of '__builtin_ia32_psrlq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h: In function '_mm_srli_si64': C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:715: error: incompatible type for argument 1 of '__builtin_ia32_psrlq' C:\_64\mingw64\x86_64-pc-mingw32\include/mmintrin.h:715: error: incompatible type for argument 2 of '__builtin_ia32_psrlq' In file included from C:\_64\mingw64\x86_64-pc-mingw32\include/emmintrin.h:43, from C:\_64\mingw64\x86_64-pc-mingw32\include/intrin.h:13, from C:\_64\mingw64\x86_64-pc-mingw32\include/winnt.h:1149, from C:\_64\mingw64\x86_64-pc-mingw32\include/windef.h:122, from C:\_64\mingw64\x86_64-pc-mingw32\include/windows.h:62, from try.c:1: C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h: In function '_mm_loadh_pi': C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h:754: warning: passing argument 2 of '__builtin_ia32_loadhps' from incompatible pointer type C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h: In function '_mm_storeh_pi': C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h:761: warning: passing argument 1 of '__builtin_ia32_storehps' from incompatible pointer type C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h: In function '_mm_loadl_pi': C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h:783: warning: passing argument 2 of '__builtin_ia32_loadlps' from incompatible pointer type C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h: In function '_mm_storel_pi': C:\_64\mingw64\x86_64-pc-mingw32\include/xmmintrin.h:790: warning: passing argument 1 of '__builtin_ia32_storelps' from incompatible pointer type I'm on Windows Vista Business (64). Am I doing something stupid ? Is this a known issue ? C:\>gcc -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 --pre fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 Thread model: win32 gcc version 4.4.0 20080507 (experimental) (GCC) I got the same behaviour with the 20080320 build. Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-05-18 06:47:18
|
On 5/18/08, Sisyphus <sis...@op...> wrote: > Hi, > > C:\>type try.c > #include <windows.h> > > int main(void) { > return 1; > } > > C:\>gcc -o try.exe try.c Do this: gcc -o try.exe try.c -v (ie, add -v to your compile command) Post the output of that. |
From: Sisyphus <sis...@op...> - 2008-05-18 07:34:30
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> To: "Sisyphus" <sis...@op...> Cc: <min...@li...> Sent: Sunday, May 18, 2008 4:47 PM Subject: Re: [Mingw-w64-public] Cannot #include <windows.h> > On 5/18/08, Sisyphus <sis...@op...> wrote: >> Hi, >> >> C:\>type try.c >> #include <windows.h> >> >> int main(void) { >> return 1; >> } >> >> C:\>gcc -o try.exe try.c > > Do this: > > gcc -o try.exe try.c -v C:\_64>gcc -o try.exe try.c -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 --pre fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 Thread model: win32 gcc version 4.4.0 20080507 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' cc1 -quiet -v -iprefix c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/ try.c -quiet -dumpbase try.c -mtune=generic -auxbase try -version -o ./ccX0Z06C.s ignoring nonexistent directory "c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/include" ignoring nonexistent directory "c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed" ignoring nonexistent directory "c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/../../ ../../x86_64-pc-mingw32/include" ignoring nonexistent directory "/var/tmp/w64/var/tmp/w64/lib/gcc/x86_64-pc-mingw 32/4.4.0/../../../../include" ignoring nonexistent directory "c:/lib/gcc/x86_64-pc-mingw32/4.4.0/include" ignoring nonexistent directory "c:/lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed " ignoring nonexistent directory "c:/x86_64-pc-mingw32/include" ignoring nonexistent directory "/var/tmp/w64/mingw/include64" #include "..." search starts here: #include <...> search starts here: C:\_64\mingw64\x86_64-pc-mingw32\include C:\_64\mingw64\include End of search list. GNU C (GCC) version 4.4.0 20080507 (experimental) (x86_64-pc-mingw32) compiled by GNU C version 4.4.0 20080507 (experimental), GMP version 4.2 .2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0f40953745fdef6c54a0febc9b9d5e92 [Then follows the errors and warnings posted in my first post.] Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-05-18 15:09:40
|
On 5/18/08, Sisyphus <sis...@op...> wrote: > > ----- Original Message ----- From: "NightStrike" <nig...@gm...> > To: "Sisyphus" <sis...@op...> > Cc: <min...@li...> > Sent: Sunday, May 18, 2008 4:47 PM > Subject: Re: [Mingw-w64-public] Cannot #include <windows.h> > > > > On 5/18/08, Sisyphus <sis...@op...> wrote: > > > > > Hi, > > > > > > C:\>type try.c > > > #include <windows.h> > > > > > > int main(void) { > > > return 1; > > > } > > > > > > C:\>gcc -o try.exe try.c > > > > > > > Do this: > > > > gcc -o try.exe try.c -v > > > > C:\_64>gcc -o try.exe try.c -v > Using built-in specs. > Target: x86_64-pc-mingw32 > Configured with: ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 > --pre > fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 > Thread model: win32 > gcc version 4.4.0 20080507 (experimental) (GCC) > COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' > cc1 -quiet -v -iprefix > c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/ try.c -quiet > -dumpbase try.c -mtune=generic -auxbase try -version -o ./ccX0Z06C.s > ignoring nonexistent directory > "c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/include" > ignoring nonexistent directory This looks wrong. The zip file that you downloaded should be extracted into some directory (say c:\win64). Then the /bin directory off of that needs to be put into your PATH: PATH=C:\win64\bin;%PATH% Is that what you did? Can you show me your PATH (type: PATH). Also, can you explain how you installed it, and tell me what the full path is to the gcc that's being called when you type "gcc". |
From: Sisyphus <sis...@op...> - 2008-05-19 02:31:20
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> . . >> C:\_64>gcc -o try.exe try.c -v >> Using built-in specs. >> Target: x86_64-pc-mingw32 >> Configured with: >> ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 >> --pre >> fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 >> Thread model: win32 >> gcc version 4.4.0 20080507 (experimental) (GCC) >> COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' >> cc1 -quiet -v -iprefix >> c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/ try.c -quiet >> -dumpbase try.c -mtune=generic -auxbase try -version -o ./ccX0Z06C.s >> ignoring nonexistent directory >> "c:\_64\../lib/gcc/x86_64-pc-mingw32/4.4.0/include" >> ignoring nonexistent directory > > This looks wrong. Agreed. > > The zip file that you downloaded should be extracted into some > directory (say c:\win64). Then the /bin directory off of that needs > to be put into your PATH: PATH=C:\win64\bin;%PATH% > > Is that what you did? I unzipped into C:\_64\mingw64 - which is not a top level folder as you have recommended. I don't know if that's significant, but let's give it a try. Firstly I remove the C:\_64\mingw64 folder entirely. Then unzip mingw-w64-bin_x86_64-mingw_20080507.zip into C:\mingw64. =================================== C:\C>path PATH=c:\ruby\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\batch C:\C>type hello.c #include <stdio.h> int main(void) { printf("Hello World\n"); } C:\C>gcc -o hello.exe hello.c 'gcc' is not recognized as an internal or external command, operable program or batch file. C:\C>set PATH=C:\mingw64\bin;%PATH% C:\C>gcc -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 --pr fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 Thread model: win32 gcc version 4.4.0 20080507 (experimental) (GCC) C:\C>gcc -o hello.exe hello.c gcc: CreateProcess: No such file or directory =================================== Yep - we're on Windows Vista (oh, joy !!). But I can fix that error: =================================== C:\C>set PATH=C:\mingw64\libexec\gcc\x86_64-pc-mingw32\4.4.0;%PATH% C:\C>gcc -o hello.exe hello.c hello.c:1:19: error: no include path in which to search for stdio.h hello.c: In function 'main': hello.c:4: warning: incompatible implicit declaration of built-in function 'printf' C:\C> =================================== I can fix that, too, by setting the CPATH environment variable. Only problem is there are 2 instances of the standard headers - one instance in C:\mingw64\mingw\include, and one in C:\mingw64\x86_64-pc-mingw32\include. Which instance needs to be found ? I'll try putting the latter first: =================================== C:\C>set CPATH=C:\mingw64\x86_64-pc-mingw32\include;C:\mingw64\include C:\C>gcc -o hello.exe hello.c ld: crt2.o: No such file: No such file or directory C:\C> =================================== Need to set the LIBRARY_PATH environment variable, too: =================================== C:\C>set LIBRARY_PATH=C:\mingw64\x86_64-pc-mingw32\lib C:\C>gcc -o hello.exe hello.c ld: cannot find -lgcc C:\C>set LIBRARY_PATH=%LIBRARY_PATH%;C:\mingw64\lib\gcc\x86_64-pc-mingw32\4.4.0 C:\C>gcc -o hello.exe hello.c C:\C>hello Hello World C:\C> =================================== Ok - let's return to try.c: =================================== C:\C>type try.c #include <windows.h> int main(void) { return 1; } C:\C> =================================== First attempt at building that produces a mass of errors beginning with: C:\mingw64\x86_64-pc-mingw32\include/intrin.h:13:23: error: emmintrin.h: No such file or directory C:\mingw64\x86_64-pc-mingw32\include/intrin.h:14:23: error: xmmintrin.h: No such file or directory C:\mingw64\x86_64-pc-mingw32\include/intrin.h:15:22: error: mmintrin.h: No such file or directory So let's add the location of those includes to the CPATH environment variable: =================================== C:\C>set CPATH=%CPATH%;C:\mingw64\lib\gcc\x86_64-pc-mingw32\4.4.0\include C:\C>gcc -o try.exe try.c -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 --pre fix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 Thread model: win32 gcc version 4.4.0 20080507 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' cc1 -quiet -v -iprefix c:\c\../lib/gcc/x86_64-pc-mingw32/4.4.0/ try.c -quiet -d umpbase try.c -mtune=generic -auxbase try -version -o ./ccQicx1L.s ignoring nonexistent directory "c:\c\../lib/gcc/x86_64-pc-mingw32/4.4.0/include" ignoring nonexistent directory "c:\c\../lib/gcc/x86_64-pc-mingw32/4.4.0/include- fixed" ignoring nonexistent directory "c:\c\../lib/gcc/x86_64-pc-mingw32/4.4.0/../../.. /../x86_64-pc-mingw32/include" ignoring nonexistent directory "/var/tmp/w64/var/tmp/w64/lib/gcc/x86_64-pc-mingw 32/4.4.0/../../../../include" ignoring nonexistent directory "c:/lib/gcc/x86_64-pc-mingw32/4.4.0/include" ignoring nonexistent directory "c:/lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed " ignoring nonexistent directory "c:/x86_64-pc-mingw32/include" ignoring nonexistent directory "/var/tmp/w64/mingw/include64" #include "..." search starts here: #include <...> search starts here: C:\mingw64\x86_64-pc-mingw32\include C:\mingw64\include C:\mingw64\lib\gcc\x86_64-pc-mingw32\4.4.0\include End of search list. GNU C (GCC) version 4.4.0 20080507 (experimental) (x86_64-pc-mingw32) compiled by GNU C version 4.4.0 20080507 (experimental), GMP version 4.2 .2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0f40953745fdef6c54a0febc9b9d5e92 COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' as -o ./ccY4h6Um.o ./ccQicx1L.s COMPILER_PATH= LIBRARY_PATH=C:/mingw64/x86_64-pc-mingw32/lib/;C:/mingw64/lib/gcc/x86_64-pc-ming w32/4.4.0/ COLLECT_GCC_OPTIONS='-o' 'try.exe' '-v' '-mtune=generic' ld --sysroot=/var/tmp/w64 -Bdynamic -o try.exe C:/mingw64/x86_64-pc-mingw32/lib /crt2.o C:/mingw64/x86_64-pc-mingw32/lib/crtbegin.o -LC:/mingw64/x86_64-pc-mingw 32/lib -LC:/mingw64/lib/gcc/x86_64-pc-mingw32/4.4.0 ./ccY4h6Um.o -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw3 2 -lgcc -lmoldname -lmingwex -lmsvcrt C:/mingw64/x86_64-pc-mingw32/lib/crtend.o =================================== That seems to have compiled ok. I guess those "ignoring nonexistent directory" messages might arise from having set the CPATH and LIBRARY_PATH variables. We'll just rewrite try.c so that it produces some output: =================================== C:\C>type try.c #include <stdio.h> #include <windows.h> int main(void) { printf("At last !!\n"); } C:\C>gcc -o try.exe try.c C:\C>try At last !! C:\C> =================================== Beautiful !! As to what the problem *was* is now a little unclear to me. Perhaps it was because I originally unzipped into C:\_64\mingw64 instead of a top level folder. Or perhaps it was something to do with the way I had jumped through all those hoops. In the process of the re-installation, I've rewritten the batch file that sets up the environment - so I can't even go back and take a look at how it was. (Well, not easily, anyway.) Is the order in which the various (CPATH and LIBRARY_PATH) locations are listed going to be of importance ? One way or another, progress has been made. Thanks for the assistance. Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-05-19 02:56:33
|
On 5/18/08, Sisyphus <sis...@op...> wrote: > As to what the problem *was* is now a little unclear to me. Perhaps it was > because I originally unzipped into C:\_64\mingw64 instead of a top level > folder. Or perhaps it was something to do with the way I had jumped through > all those hoops. First, the level of the directory path doesn't matter. You can install it into C:\a\b\c\d\e\f\g\mylongdir\another\dir\soemthingnotnamedmingw As long as you put: C:\a\b\c\d\e\f\g\mylongdir\another\dir\soemthingnotnamedmingw\bin in your PATH, everything should be ok. > In the process of the re-installation, I've rewritten the batch file that > sets up the environment - so I can't even go back and take a look at how it > was. (Well, not easily, anyway.) > > Is the order in which the various (CPATH and LIBRARY_PATH) locations are > listed going to be of importance ? This is what is troubling. You shouldn't have had to go do all of that. I noticed that your first error was the Vista CreateProcess thing. That is surprising, as I thought that I tested that fully, and someone named "fx" made the ACCESS method be Vista-compatible by default. I can say that it definitely isn't required with the Win32 cross compiler running on Vista64, as I installed that just today (dated 20080428) and Hello World works great. I see you are getting around the CreateProcess issue by calling the compiler directly instead of using the front end. This is a dangerous area to be in. I will spin a completely new fresh version of the toolchain (maybe there was an error in there somewhere), run it on my Vista64 machine, compile Hello World, and if it works, I'll upload it. You can also stop by irc.oftc.net/#mingw-w64 if you like IRC and maybe it'll be easier to work 1-on-1 there. |
From: Sisyphus <sis...@op...> - 2008-05-19 03:46:47
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> . . > > I will spin a completely new fresh version of the toolchain (maybe > there was an error in there somewhere), run it on my Vista64 machine, > compile Hello World, and if it works, I'll upload it. Let me know when that's done and I'll certainly give it a try. (I'll be a bit pre-occupied with work over the next few days, but I'll still find some time to try things out.) This is about the fourth binary build of mingw64 that I've tried. All have suffered from the access() problem (for me, at least). Thanks, NightStrike. Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-06-02 00:09:12
|
On 5/18/08, Sisyphus <sis...@op...> wrote: > > ----- Original Message ----- From: "NightStrike" <nig...@gm...> > . > . > > > > I will spin a completely new fresh version of the toolchain (maybe > > there was an error in there somewhere), run it on my Vista64 machine, > > compile Hello World, and if it works, I'll upload it. > > > > Let me know when that's done and I'll certainly give it a try. (I'll be a > bit pre-occupied with work over the next few days, but I'll still find some > time to try things out.) This is about the fourth binary build of mingw64 > that I've tried. All have suffered from the access() problem (for me, at > least). Please try the latest version, dated 0528 for x86_64-mingw. You will probably have to specify the link time libraries on the command line (-lkernel32, etc). That bug will be fixed tomorrow. However, this should work for access() purposes. It works on my Vista machine. Creating the process fails long before it searches for libraries, obviously =) Let me know how it goes. |
From: Sisyphus <sis...@op...> - 2008-06-02 02:07:44
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> . . > > Please try the latest version, dated 0528 for x86_64-mingw. You will > probably have to specify the link time libraries on the command line > (-lkernel32, etc). That bug will be fixed tomorrow. However, this > should work for access() purposes. It works on my Vista machine. > Creating the process fails long before it searches for libraries, > obviously =) > > Let me know how it goes. Not so goodly: --------------------------------------------- C:\_64\C>path PATH=C:\_32\dmake;C:\_64\mingw64\bin;c:\ruby\bin;C:\Windows\system32;C:\Windows; C:\Windows\System32\Wbem;C:\batch C:\_64\C>gcc -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../gcc/configure -q --prefix=/var/tmp/w64 --with-sysroot=/var/tmp/w64 --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --silent Thread model: win32 gcc version 4.4.0 20080528 (experimental) (GCC) C:\_64\C>type try.c #include <stdio.h> #include <inttypes.h> #include <windows.h> int main() { printf("%d\n", sizeof(uint64_t)); return 0; } C:\_64\C>gcc -o try.exe try.c gcc: CreateProcess: No such file or directory C:\_64\C> --------------------------------------------- Same result if I put MinGW in C:\mingw64. (But that shouldn't surprise.) And it makes no difference whether I use the Windows/SysWOW64/cmd.exe shell or the Windows/System32/cmd.exe shell. What on Earth could be doing this ? It's Windows Vista Business, and an AMD Athlon 64 X2 Dual Core Processor 4600+. There's no such problem with the current mingw32 (gcc-3.4.5) binaries. Cheers, Rob |
From: J. L. <lit...@gm...> - 2008-05-18 20:30:08
|
On 5/18/08, Sisyphus <sis...@op...> wrote: > Hi, > > C:\>type try.c > #include <windows.h> > > int main(void) { > return 1; > } > This should be no problem. Maybe you did not properly set the environments. I use different source that already has mthread (openmp). For example, C:\temp\c>more a.c #include <windows.h> int main(void) { return 1; } C:\temp\c>gcc -o a.exe a.c C:\temp\c>dir a.exe Volume in drive C has no label. Volume Serial Number is 788C-5FA0 Directory of C:\temp\c 05/18/2008 04:15 PM 8,704 a.exe 1 File(s) 8,704 bytes 0 Dir(s) 6,770,716,672 bytes free C:\temp\c>gcc -v Built by Equation Solution (http://www.Equation.com). Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../gcc-4.4-20080516-mingw/configure --host=x86_64-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gcc/4.4-20080516 --with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/4.4-20080516 --with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls --disable-tls --enable-languages=c,fortran --enable-threads=win32 --enable-libgomp --disable-win32-registry Thread model: win32 gcc version 4.4.0 20080516 (experimental) (GCC) C:\temp\c> |
From: Sisyphus <sis...@op...> - 2008-06-02 04:37:55
|
----- Original Message ----- From: "Sisyphus" <sis...@op...> . . > > C:\_64\C>gcc -o try.exe try.c > gcc: CreateProcess: No such file or directory > Hmmm ... this is slightly different to what happens when I try to build try.c using a mingw32 that *doesn't* have the access() fix: C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c gcc: installation problem, cannot exec `cc1': No such file or directory Could it be that, re mingw64, I'm being hit by something other than the access() problem ? Here's 'gcc-v' for that particular mingw32: C:\_64\C>\strawberry\c\bin\gcc -v Reading specs from /strawberry/c/lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) (I think it's just one of the binary builds provided by the MinGW project.) Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-06-02 15:05:24
|
On 6/2/08, Sisyphus <sis...@op...> wrote: > > ----- Original Message ----- From: "Sisyphus" <sis...@op...> > . > . > > > > C:\_64\C>gcc -o try.exe try.c > > gcc: CreateProcess: No such file or directory > > > > > > Hmmm ... this is slightly different to what happens when I try to build > try.c using a mingw32 that *doesn't* have the access() fix: > > C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c > gcc: installation problem, cannot exec `cc1': No such file or directory > > Could it be that, re mingw64, I'm being hit by something other than the > access() problem ? It's entirely possible. It also might be a permissions issue. I'm running the 0528 build with Vista 64 Ultimate, UAC turned **on**, and the user account in the administrators group. I'm running with SP1 installed and all the recent updates. I can compile and run a simple hello world (just including stdio.h), as well as your test application (just including windows.h). I did this in C:\mingw as well as C:\_64. all I do is put (dir)\bin in the front of my PATH, and it works. Do you have cygwin installed? Are you getting a naming collision? Try using the canonicalized name -- x86_64-pc-mingw32-gcc. It should be in the \bin directory as well. > Here's 'gcc-v' for that particular mingw32: > > C:\_64\C>\strawberry\c\bin\gcc -v > Reading specs from > /strawberry/c/lib/gcc/mingw32/3.4.5/specs > Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld > --with-gnu-as - > -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads > --disable-nls -- > enable-languages=c,c++,f77,ada,objc,java > --disable-win32-registry --disable-shar > ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x > --ena > ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter > --enable-hash-sync > hronization --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw special) > > (I think it's just one of the binary builds provided by the MinGW project.) > > Cheers, > Rob > > |
From: Sisyphus <sis...@op...> - 2008-06-03 01:25:49
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> To: "Sisyphus" <sis...@op...> Cc: <min...@li...> Sent: Tuesday, June 03, 2008 1:05 AM Subject: Re: [Mingw-w64-public] Cannot #include <windows.h> . . > I'm running with SP1 > installed and all the recent updates. Windows Update installs updates every day - but doesn't install SP1. Installing SP1 seems to have fixed the problem ... which is, no doubt, a relief to *both* of us. (At least that test program builds and runs correctly.) Thanks, NightStrike. Cheers, Rob |
From: NightStrike <nig...@gm...> - 2008-06-03 07:04:39
|
On 6/2/08, Sisyphus <sis...@op...> wrote: > > ----- Original Message ----- From: "NightStrike" <nig...@gm...> > To: "Sisyphus" <sis...@op...> > Cc: <min...@li...> > Sent: Tuesday, June 03, 2008 1:05 AM > Subject: Re: [Mingw-w64-public] Cannot #include <windows.h> > . > . > > I'm running with SP1 > > installed and all the recent updates. > > > > Windows Update installs updates every day - but doesn't install SP1. > Installing SP1 seems to have fixed the problem ... which is, no doubt, a > relief to *both* of us. (At least that test program builds and runs > correctly.) > > Thanks, NightStrike. A relief indeed! I had no idea whatsoever what else to suggest! I guess at this point I should put somewhere on the site that Vista support requires SP1. |