From: Kai T. <Kai...@on...> - 2007-12-21 08:54:51
|
SGkgUm9iLA0KDQpJIHJlZGlyZWN0IHlvdSB0byB0aGUgbWluZ3ctNjQgcHVibGljIGdyb3VwLCB3 aGVyZSBpdCBpcyBtb3JlIGxpa2x5LCB0aGF0IA0Kc29tZWJvZHkgY2FuIGhlbHAgeW91Lg0KDQo+ IFNvbWUgdGltZSBiYWNrIEkgZG93bmxvYWRlZCBhIE1pbkdXIDY0IGJpbmFyeSAtIG5vdCBzdXJl IGV4YWN0bHkgd2hlcmUgDQpmcm9tLCANCj4gYnV0IGl0IHdhcyBhIGxpbmsgdGhhdCBjYW1lIGZy b20gdGhpcyBsaXN0IChhbmQgSSBjb3VsZCBwcm9iYWJseSB0cmFjayANCml0IA0KPiBkb3duIGlm IGl0J3MgaW1wb3J0YW50KS4NCj4gDQo+IEFueXdheSAuLi4uIHRoYXQgYmluYXJ5IHlpZWxkczoN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEM6XD5cXzY0 XE1pbkdXXHRhcmdldFxiaW5cZ2NjIC12DQo+IFVzaW5nIGJ1aWx0LWluIHNwZWNzLg0KPiBUYXJn ZXQ6IHg4Nl82NC1wYy1taW5ndzMyDQo+IENvbmZpZ3VyZWQgd2l0aDogDQo+IC4uL2djYy9jb25m aWd1cmUgLS1ob3N0PXg4Nl82NC1wYy1taW5ndzMyIC0tdGFyZ2V0PXg4Nl82NC1wYy1taW5ndzMy DQo+IC0tZW5hYmxlLWxhbmd1YWdlcz1jLGMrKyANCj4gIC0tZGlzYWJsZS1ubHMgLS1kaXNhYmxl LW11bHRpbGliIC0tZGlzYWJsZS1saWJzdGRjeHgtcGNoIA0KLS1lbmFibGUtbG9uZy1sb25nIA0K PiAgLS13aXRoLWdtcD0vaG9tZS96aG91amcvbWluZ3cvZm9yX3RhcmdldCANCi0tcHJlZml4PS9o b21lL3pob3VqZy9taW5ndy90YXJnZXQNCj4gVGhyZWFkIG1vZGVsOiB3aW4zMg0KPiBnY2MgdmVy c2lvbiA0LjMuMCAyMDA3MDkzMCAoZXhwZXJpbWVudGFsKSAoR0NDKQ0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVW5mb3J0dW5hdGVseSwgaWYgSSB0cnkg dG8gYnVpbGQgYSBzaW1wbGUgQyBzY3JpcHQgdXNpbmcgdGhhdCBjb21waWxlciBJIA0KDQo+IGdl dDoNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQzpcXzY0 XEM+XF82NFxNaW5HV1x0YXJnZXRcYmluXGdjYyAtbyB0cnkuZXhlIHRyeS5jDQo+IGdjYzogQ3Jl YXRlUHJvY2VzczogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIYXZlIHlvdSBzZXQgeW91ciBQQVRIIGVudmlyb25t ZW50IHZhcmlhYmxlIHRvIHRoZSB0YXJnZXQgYmluIGRpcmVjdG9yeSA/DQogDQo+IFdoZXJlIHRv IGZyb20gaGVyZSA/DQoNCj4gT25lIG90aGVyIHF1ZXN0aW9uIC0gaWYgSSB3YW50ZWQgdG8gYnVp bGQgTWluR1cgNjQgZnJvbSBzb3VyY2UsIHdvdWxkIEkgDQpuZWVkIA0KPiBhIDY0LWJpdCBsaW51 eCBib3ggPyAuLi4gb3IgY2FuIGl0IGJlIGNyb3NzLWNvbXBpbGVkIHVzaW5nIGEgMzItYml0IA0K bGludXggDQo+IGJveCA/DQoNCllvdSB3b250IG5lZWQgYSA2NC1iaXQgbWFjaGluZSB0byBidWls ZCwgYnV0IG9mIGNvdXJzZSBzdWNoIGEgbWFjaGluZSBmb3IgDQpleGVjdXRpbmcgdGhlIGdlbmVy YXRlZCBleGVjdXRhYmxlcyA7KS4gSWYgeW91IHRha2UgYSBsb29rIGF0IHRoZSANCm1pbmd3LXc2 NCBwcm9qZWN0LCB0aGVyZSBhcmUgc2V2ZXJhbCBjcm9zcyBjb21waWxlcnMgYXMgYmluYXJ5IHBh Y2thZ2VzIA0KYXZhaWxhYmxlLiBUaGVyZSBpcyBhbHNvIHRoZSBjdXJyZW50IHNvdXJjZSBvZiB0 aGUgY3J0IGFuZCBhIGhvdyB0byBidWlsZCANCnRoZSBnY2MgdG9vbGNoYWluLg0KDQo+IChDYW4g aXQgYmUgYnVpbHQgdXNpbmcgQ3lnd2luIG9uIGEgMzItYml0ICp3aW5kb3dzKiBib3ggPykNCk9m IGNvdXJzZSB5b3UgYXJlIGFibGUgdG8gdXNlIHRoZSBjeWd3aW4gc2hlbGwgZm9yIGJ1aWxkaW5n IGEgY3Jvc3MgDQpjb21waWxlci4NCg0KQ2hlZXJzLA0KIGkuQS4gS2FpIFRpZXR6DQoNCnwgIChc Xy8pICBUaGlzIGlzIEJ1bm55LiBDb3B5IGFuZCBwYXN0ZSBCdW5ueQ0KfCAoPScuJz0pIGludG8g eW91ciBzaWduYXR1cmUgdG8gaGVscCBoaW0gZ2Fpbg0KfCAoIilfKCIpIHdvcmxkIGRvbWluYXRp b24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBPbmVWaXNpb24gU29m dHdhcmUgRW50d2lja2x1bmdzIEdtYkggJiBDby4gS0cNCiAgRHIuLUxlby1SaXR0ZXItU3RyYcOf ZSA5IC0gOTMwNDkgUmVnZW5zYnVyZw0KICBUZWw6ICs0OS4oMCk5NDEuNzgwMDQuMCAtIEZheDog KzQ5LigwKTk0MS43ODAwNC40ODkgLSB3d3cuT25lVmlzaW9uLmNvbQ0KICBDb21tZXJ6YmFuayBS ZWdlbnNidXJnIC0gQkxaIDc1MCA0MDAgNjIgLSBLb250byA2MDExMDUwDQogIEhhbmRlbHNyZWdp c3RlcjogSFJBIDY3NDQsIEFtdHNnZXJpY2h0IFJlZ2Vuc2J1cmcNCiAgS29tcGxlbWVudMOkcmlu OiBPbmVWaXNpb24gU29mdHdhcmUgRW50d2lja2x1bmdzIFZlcndhbHR1bmdzIEdtYkgNCiAgRHIu LUxlby1SaXR0ZXItU3RyYcOfZSA5IOKAkyA5MzA0OSBSZWdlbnNidXJnDQogIEhhbmRlbHNyZWdp c3RlcjogSFJCIDg5MzIsIEFtdHNnZXJpY2h0IFJlZ2Vuc2J1cmcgLSBHZXNjaMOkZnRzZsO8aHJl cjogDQpVbHJpa2UgRMO2aGxlciwgTWFudWVsYSBLbHVnZXINCg0K |
From: Danny S. <dan...@cl...> - 2007-12-25 22:11:59
|
> though I've since tried setting the path to > C:\_64\root-x86_64-pc-mingw32\bin (and nothing else) ... > without success. > > I've also since tried the "-c" compile only switch, but I > still get the same > error: > > ------------------------------------- > C:\_64\C>gcc -c try.c > gcc: CreateProcess: No such file or directory > ------------------------------------- This error message comes from pex_win32_exec_child in libiberty/pex-win32.c. I suspect that the process it is trying to create is cc1.exe. I would not be surprised if the reason it can't find it is that the _access() function on Vista64 has the same behaviour as _access() on Vista32. Do the mingw-w64 headers have the __MINGW_ACCESS workaround? See PR 33281 in gcc's bugzilla for details. Danny |
From: Sisyphus <sis...@op...> - 2008-01-01 07:51:37
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> . . >> ------------------------------------- >> C:\_64\C>gcc -c try.c >> gcc: CreateProcess: No such file or directory >> ------------------------------------- > This error message comes from pex_win32_exec_child in > libiberty/pex-win32.c. > I suspect that the process it is trying to create is cc1.exe. > I would not be surprised if the reason it can't find it is that > the _access() function on Vista64 has the same behaviour as _access() > on Vista32. > Do the mingw-w64 headers have the __MINGW_ACCESS workaround? > See PR 33281 in gcc's bugzilla for details. > Danny Yes - I was wondering if that might be the cause, and it does seem to be the trouble. If I add C:\_64\root-x86_64-pc-mingw32\libexec\gcc\x86_64-pc-mingw32\4.3.0 to the path (so that cc1.exe is locatable) then the error disappears, to be replaced with: ---------------------- C:\_64\C>gcc -o try.exe try.c try.c:1:19: error: no include path in which to search for stdio.h try.c: In function 'main': try.c:4: warning: incompatible implicit declaration of built-in function 'printf' ---------------------- This is the same error as occurs with the 32-bit version of gcc.exe (that doesn't incorporate the __MINGW_ACCESS workaround) once the location of cc1.exe has been added to the path. Cheers, Rob |
From: JonY <10...@gm...> - 2008-01-01 08:10:19
|
Sisyphus wrote: > ----- Original Message ----- > From: "Danny Smith" <dan...@cl...> > . > . >>> ------------------------------------- >>> C:\_64\C>gcc -c try.c >>> gcc: CreateProcess: No such file or directory >>> ------------------------------------- >> This error message comes from pex_win32_exec_child in >> libiberty/pex-win32.c. >> I suspect that the process it is trying to create is cc1.exe. >> I would not be surprised if the reason it can't find it is that >> the _access() function on Vista64 has the same behaviour as _access() >> on Vista32. >> Do the mingw-w64 headers have the __MINGW_ACCESS workaround? >> See PR 33281 in gcc's bugzilla for details. >> Danny > > Yes - I was wondering if that might be the cause, and it does seem to be the > trouble. > If I add C:\_64\root-x86_64-pc-mingw32\libexec\gcc\x86_64-pc-mingw32\4.3.0 > to the path (so that cc1.exe is locatable) then the error disappears, to be > replaced with: > > ---------------------- > C:\_64\C>gcc -o try.exe try.c > try.c:1:19: error: no include path in which to search for stdio.h > try.c: In function 'main': > try.c:4: warning: incompatible implicit declaration of built-in function > 'printf' > ---------------------- > > This is the same error as occurs with the 32-bit version of gcc.exe (that > doesn't incorporate the __MINGW_ACCESS workaround) once the location of > cc1.exe has been added to the path. > > Cheers, > Rob > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Hi, GCC can't find the mingw64 headers. IMHO its the dreaded non-relocatable prefix, a rebuild may be needed. Your first message indicated gcc is configured with "--prefix=/home/zhoujg/mingw/target". gcc is probably searching $PREFIX/include for headers (and likely cc1.exe in $PREFIX as well), but not anywhere in C:\_64. I experienced the same problem when moving a gcc install from C:\MinGW to another drive. |
From: Danny S. <dan...@cl...> - 2008-01-01 09:45:32
|
> . > >> ------------------------------------- > >> C:\_64\C>gcc -c try.c > >> gcc: CreateProcess: No such file or directory > >> ------------------------------------- > > This error message comes from pex_win32_exec_child in > > libiberty/pex-win32.c. > > I suspect that the process it is trying to create is cc1.exe. > > I would not be surprised if the reason it can't find it is that > > the _access() function on Vista64 has the same behaviour as > _access() > > on Vista32. > > Do the mingw-w64 headers have the __MINGW_ACCESS workaround? > > See PR 33281 in gcc's bugzilla for details. > > Danny > > Yes - I was wondering if that might be the cause, and it does > seem to be the > trouble. > If I add > C:\_64\root-x86_64-pc-mingw32\libexec\gcc\x86_64-pc-mingw32\4.3.0 > to the path (so that cc1.exe is locatable) then the error > disappears, to be > replaced with: > > ---------------------- > C:\_64\C>gcc -o try.exe try.c > try.c:1:19: error: no include path in which to search for stdio.h > try.c: In function 'main': > try.c:4: warning: incompatible implicit declaration of > built-in function > 'printf' > ---------------------- > > This is the same error as occurs with the 32-bit version of > gcc.exe (that > doesn't incorporate the __MINGW_ACCESS workaround) once the > location of > cc1.exe has been added to the path. You will need to do the right thing in mingw64 headers re: > > Do the mingw-w64 headers have the __MINGW_ACCESS workaround? Then add the __USE_MINGW_ACCESS to CFLAGS. This is what the top level config/mh-mingw file host fragment does in GCC trunk: # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows # Vista (see PR33281 for details). BOOT_CFLAGS += -D__USE_MINGW_ACCESS BTW, this thread is an example of the kind of confusion that is bound to arise with separate mingw64/mingw32 developement. Although mh-mingw is (or should be) used for ming64 host. it won't do anything with mingw64 headers. Danny > Cheers, > Rob > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Sisyphus <sis...@op...> - 2008-01-01 12:12:28
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> . . > You will need to do the right thing in mingw64 headers re: Nope ... not *me* ... I know jack-shit about how to build MinGW. (Didn't you see my other post to the MinGW Users List titled "Ready to build g77 for Vista" ? ) My New Year's Resolution is to have a g77.exe that works with gcc-3.4.5 (32-bit) on Vista by the end of 2008. Current indications are that it will take about 12 months for me to achieve that :-) However, in all seriousness - thanks for that reply. I hope the guys that are actively working on the 64-bit version of MinGW can put your advice to good use. Cheers, Rob |
From: zhou d. <dra...@gm...> - 2007-12-21 09:02:35
|
2007/12/21, Kai Tietz <Kai...@on...>: > Hi Rob, > > I redirect you to the mingw-64 public group, where it is more likly, that > somebody can help you. > > > Some time back I downloaded a MinGW 64 binary - not sure exactly where > from, > > but it was a link that came from this list (and I could probably track > it > > down if it's important). > > > > Anyway .... that binary yields: > > > > -------------------------------------- > > C:\>\_64\MinGW\target\bin\gcc -v > > Using built-in specs. > > Target: x86_64-pc-mingw32 > > Configured with: > > ../gcc/configure --host=3Dx86_64-pc-mingw32 --target=3Dx86_64-pc-mingw3= 2 > > --enable-languages=3Dc,c++ > > --disable-nls --disable-multilib --disable-libstdcxx-pch > --enable-long-long > > --with-gmp=3D/home/zhoujg/mingw/for_target > --prefix=3D/home/zhoujg/mingw/target > > Thread model: win32 > > gcc version 4.3.0 20070930 (experimental) (GCC) > > -------------------------------------- > > > > Unfortunately, if I try to build a simple C script using that compiler = I > > > get: > > > > -------------------------------------- > > C:\_64\C>\_64\MinGW\target\bin\gcc -o try.exe try.c > > gcc: CreateProcess: No such file or directory > > -------------------------------------- > > Have you set your PATH environment variable to the target bin directory ? This may be caused by the link problem, some link file in the tar package, If you untar them to windows filesystem, they will become zero length file. Try replace the zero length fie to the link target file. Or try newer package in http://sourceforge.net/projects/mingw-w64/ or my website http://www.drangon.org/mingw/ BTW: the mingw-w64 *native* compiler still not so stable, especially when compiling large c++ source code. I recommand built a cross compiler under linux or cygwin, and use the cross compiler to build program that runs in native win 64 platform. > > > Where to from here ? > > > One other question - if I wanted to build MinGW 64 from source, would I > need > > a 64-bit linux box ? ... or can it be cross-compiled using a 32-bit > linux > > box ? > > You wont need a 64-bit machine to build, but of course such a machine for > executing the generated executables ;). If you take a look at the > mingw-w64 project, there are several cross compilers as binary packages > available. There is also the current source of the crt and a how to build > the gcc toolchain. > > > (Can it be built using Cygwin on a 32-bit *windows* box ?) > Of course you are able to use the cygwin shell for building a cross > compiler. > > Cheers, > i.A. Kai Tietz > > | (\_/) This is Bunny. Copy and paste Bunny > | (=3D'.'=3D) into your signature to help him gain > | (")_(") world domination. > > -------------------------------------------------------------------------= ----------------- > OneVision Software Entwicklungs GmbH & Co. KG > Dr.-Leo-Ritter-Stra=DFe 9 - 93049 Regensburg > Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com > Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 > Handelsregister: HRA 6744, Amtsgericht Regensburg > Komplement=E4rin: OneVision Software Entwicklungs Verwaltungs GmbH > Dr.-Leo-Ritter-Stra=DFe 9 =96 93049 Regensburg > Handelsregister: HRB 8932, Amtsgericht Regensburg - Gesch=E4ftsf=FChrer= : > Ulrike D=F6hler, Manuela Kluger > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: NightStrike <nig...@gm...> - 2007-12-21 09:20:08
|
On 12/21/07, Kai Tietz <Kai...@on...> wrote: > Hi Rob, > > I redirect you to the mingw-64 public group, where it is more likly, that > somebody can help you. https://sourceforge.net/projects/mingw-w64 There's the link for you ;-) > > Some time back I downloaded a MinGW 64 binary - not sure exactly where > from, Based on the output of gcc -v, it's one of zhou's releases. That's probably why he replied to you, as well =) His site is linked to from the w64 project webpage that I linked to you up above. |
From: Sisyphus <sis...@op...> - 2007-12-23 02:00:01
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> . . > > https://sourceforge.net/projects/mingw-w64 > Having installed mingw-w64-bin_x86_64-mingw32_20071203.tar.bz2 from https://sourceforge.net/project/showfiles.php?group_id=202880 and amended the path appropriately, I still get the same error: ------------------------------------------------------- C:\_64\C>gcc -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: /tmp/rt/build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 --prefix=/tmp/rt/native --with-sysroot=/tmp/rt/native --host=x86_64-pc-mingw32 Thread model: win32 gcc version 4.3.0 20071203 (experimental) (GCC) C:\_64\C>type try.c #include <stdio.h> int main() { printf("hello world\n"); return 0; } C:\_64\C>gcc -o try.exe try.c gcc: CreateProcess: No such file or directory C:\_64\C> ------------------------------------------------------- Is this a Vista-specific problem ? (Has anyone successfully used these binaries on Vista 64 ?) Not exactly sure whether I should be following up on the MinGW-64 list or the MinGW list. Thanks for the replies, guys. Cheers, Rob |
From: NightStrike <nig...@gm...> - 2007-12-23 02:45:17
|
On 12/22/07, Sisyphus <sis...@op...> wrote: > Having installed mingw-w64-bin_x86_64-mingw32_20071203.tar.bz2 from > https://sourceforge.net/project/showfiles.php?group_id=202880 and amended > the path appropriately, I still get the same error: > > ------------------------------------------------------- > C:\_64\C>gcc -v > Using built-in specs. > Target: x86_64-pc-mingw32 > Configured with: > /tmp/rt/build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 > --prefix=/tmp/rt/native --with-sysroot=/tmp/rt/native --host=x86_64-pc-mingw32 > Thread model: win32 > gcc version 4.3.0 20071203 (experimental) (GCC) > > C:\_64\C>type try.c > #include <stdio.h> > > int main() { > printf("hello world\n"); > return 0; > } > > > C:\_64\C>gcc -o try.exe try.c > gcc: CreateProcess: No such file or directory Can you at least compile without linking with gcc -c? > Is this a Vista-specific problem ? (Has anyone successfully used these > binaries on Vista 64 ?) No idea... > Not exactly sure whether I should be following up on the MinGW-64 list or > the MinGW list. The mingw-w64 list is more appropriate. There's a forum there, as well. It's more closely watched, and you'll get help faster. I don't know if anyone would mind if you CC'd this list as well. > Thanks for the replies, guys. Thank me once your stuff works :) |
From: Arthur N. <ac...@ca...> - 2007-12-23 09:00:04
|
On Sat, 22 Dec 2007, NightStrike wrote: > On 12/22/07, Sisyphus <sis...@op...> wrote: >> C:\_64\C>gcc -v >> Using built-in specs. >> Target: x86_64-pc-mingw32 >> Configured with: >> /tmp/rt/build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 >> --prefix=/tmp/rt/native --with-sysroot=/tmp/rt/native --host=x86_64-pc-mingw32 >> Thread model: win32 >> gcc version 4.3.0 20071203 (experimental) (GCC) >> C:\_64\C>gcc -o try.exe try.c >> gcc: CreateProcess: No such file or directory >> Is this a Vista-specific problem ? (Has anyone successfully used these >> binaries on Vista 64 ?) > > No idea... > I have Vista Home Premium. I fetched that archive and put it in c:\_c64, then un-tarred it so everything is in c:\_c64\root. To try to avoid conflict with other things I ran a plain Windows command promt and set PATH to c:\_c64_root_bin and nothing else at all. The compiler then seems to behave OK for me, and if I give it a command-line option "-v" I can see it fetching all its components from within that tree. It could be that I have some environment variables set that something somewhere relies on (or you have some that hinder). But this response is to the "has anybody run this on vista" part of the above query, and the answer is yes! Arthur |
From: NightStrike <nig...@gm...> - 2007-12-23 10:11:13
|
On 12/23/07, Arthur Norman <ac...@ca...> wrote: > On Sat, 22 Dec 2007, NightStrike wrote: > > On 12/22/07, Sisyphus <sis...@op...> wrote: > >> C:\_64\C>gcc -v > >> Using built-in specs. > >> Target: x86_64-pc-mingw32 > >> Configured with: > >> /tmp/rt/build/gcc-svn/gcc/configure --target=x86_64-pc-mingw32 > >> --prefix=/tmp/rt/native --with-sysroot=/tmp/rt/native --host=x86_64-pc-mingw32 > >> Thread model: win32 > >> gcc version 4.3.0 20071203 (experimental) (GCC) > >> C:\_64\C>gcc -o try.exe try.c > >> gcc: CreateProcess: No such file or directory > >> Is this a Vista-specific problem ? (Has anyone successfully used these > >> binaries on Vista 64 ?) > > > > No idea... > > > I have Vista Home Premium. I fetched that archive and put it in c:\_c64, > then un-tarred it so everything is in c:\_c64\root. To try to avoid > conflict with other things I ran a plain Windows command promt and set > PATH to c:\_c64_root_bin and nothing else at all. The compiler then seems > to behave OK for me, and if I give it a command-line option "-v" I can see > it fetching all its components from within that tree. It could be that I > have some environment variables set that something somewhere relies on (or > you have some that hinder). But this response is to the "has anybody run > this on vista" part of the above query, and the answer is yes! Now see, this is what confuses me. I built that archive setting prefix and sysroot to the same directory. The gcc manual implies that to make that tarball work anywhere (as you are doing it), sysroot has to be a subdirectory of prefix. gcc -v will show you exactly how I built it... Why does what I did work at all? I've been trying to build with sysroot being a subdirectory of prefix, and not having good luck with it at all. I thought maybe that might be an issue that people are having. |
From: Sisyphus <sis...@op...> - 2007-12-24 13:48:21
|
----- Original Message ----- From: "NightStrike" <nig...@gm...> . . >> I have Vista Home Premium. I fetched that archive and put it in c:\_c64, >> then un-tarred it so everything is in c:\_c64\root. To try to avoid >> conflict with other things I ran a plain Windows command promt and set >> PATH to c:\_c64_root_bin and nothing else at all. The compiler then seems >> to behave OK for me, and if I give it a command-line option "-v" I can >> see >> it fetching all its components from within that tree. It could be that I >> have some environment variables set that something somewhere relies on >> (or >> you have some that hinder). But this response is to the "has anybody >> run >> this on vista" part of the above query, and the answer is yes! > > Now see, this is what confuses me. I built that archive setting > prefix and sysroot to the same directory. The gcc manual implies that > to make that tarball work anywhere (as you are doing it), sysroot has > to be a subdirectory of prefix. gcc -v will show you exactly how I > built it... Why does what I did work at all? I've been trying to > build with sysroot being a subdirectory of prefix, and not having good > luck with it at all. I thought maybe that might be an issue that > people are having. > I'm confused, too. After xmas is over and done with, I'll subscribe to the MinGW-64 mailing list and try again. I missed Arthur Norman's response that NightStrike has quoted above... though I've since tried setting the path to C:\_64\root-x86_64-pc-mingw32\bin (and nothing else) ... without success. I've also since tried the "-c" compile only switch, but I still get the same error: ------------------------------------- C:\_64\C>gcc -c try.c gcc: CreateProcess: No such file or directory ------------------------------------- Cheers, Rob |
From: NightStrike <nig...@gm...> - 2007-12-24 17:29:20
|
On 12/24/07, Sisyphus <sis...@op...> wrote: > I missed Arthur Norman's response that NightStrike has quoted above... > though I've since tried setting the path to > C:\_64\root-x86_64-pc-mingw32\bin (and nothing else) ... without success. > C:\_64\C>gcc -c try.c > gcc: CreateProcess: No such file or directory If you look in that directory that you put in your path, you will notice that 'gcc' is not in that directory. Instead, it's the canonicalized name: x86_64-pc-mingw32-gcc.exe. Execute that and see what happens. |
From: zhou d. <dra...@gm...> - 2007-12-25 02:18:00
|
2007/12/24, Sisyphus <sis...@op...>: > > ----- Original Message ----- > From: "NightStrike" <nig...@gm...> > . > . > >> I have Vista Home Premium. I fetched that archive and put it in c:\_c64, > >> then un-tarred it so everything is in c:\_c64\root. To try to avoid > >> conflict with other things I ran a plain Windows command promt and set > >> PATH to c:\_c64_root_bin and nothing else at all. The compiler then seems > >> to behave OK for me, and if I give it a command-line option "-v" I can > >> see > >> it fetching all its components from within that tree. It could be that I > >> have some environment variables set that something somewhere relies on > >> (or > >> you have some that hinder). But this response is to the "has anybody > >> run > >> this on vista" part of the above query, and the answer is yes! > > > > Now see, this is what confuses me. I built that archive setting > > prefix and sysroot to the same directory. The gcc manual implies that > > to make that tarball work anywhere (as you are doing it), sysroot has > > to be a subdirectory of prefix. gcc -v will show you exactly how I > > built it... Why does what I did work at all? I've been trying to > > build with sysroot being a subdirectory of prefix, and not having good > > luck with it at all. I thought maybe that might be an issue that > > people are having. > > > > I'm confused, too. After xmas is over and done with, I'll subscribe to the > MinGW-64 mailing list and try again. > > I missed Arthur Norman's response that NightStrike has quoted above... > though I've since tried setting the path to > C:\_64\root-x86_64-pc-mingw32\bin (and nothing else) ... without success. > > I've also since tried the "-c" compile only switch, but I still get the same > error: > > ------------------------------------- > C:\_64\C>gcc -c try.c > gcc: CreateProcess: No such file or directory > ------------------------------------- Can you try the following command : C:\_64\C>gcc -v try.c -o try I guess that the log "gcc: CreateProcess: No such file or directory" was caused by some missing file or path not correct. > > Cheers, > Rob > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Earnie B. <ea...@us...> - 2007-12-21 15:07:08
|
Quoting Kai Tietz <Kai...@on...>: > Hi Rob, > > I redirect you to the mingw-64 public group, where it is more likly, that > somebody can help you. > There is absolutely no reason to redirect the another list. This alternate list is not sanctioned by MinGW. Please keep discussion of MinGW on the mingw-users list. Kai, we've asked you via the mingw-dvlpr list to submit patches to incorporate your 64bit support. There is no reason to have created another project. Earnie |
From: NightStrike <nig...@gm...> - 2007-12-21 18:37:33
|
On 12/21/07, Earnie Boyd <ea...@us...> wrote: > > Quoting Kai Tietz <Kai...@on...>: > > > Hi Rob, > > > > I redirect you to the mingw-64 public group, where it is more likly, that > > somebody can help you. > > > > There is absolutely no reason to redirect the another list. This > alternate list is not sanctioned by MinGW. Please keep discussion of > MinGW on the mingw-users list. > Kai, we've asked you via the mingw-dvlpr list to submit patches to > incorporate your 64bit support. There is no reason to have created > another project. Flies and honey, Earnie. Flies and honey. Kai has his reasons for doing what he does, and I am a part of that project. Kai has been a wonderful person to work with, completely understanding of my knowledge level. He helped me get from knowing nothing about this stuff at all to actually creating the whole build system for the project. That's an awesome thing, and it serves as an example of the kind of good person he is, if you'd just take the time to listen to what he has to say. You say that there is absolutely no reason to have a separate list. Earnie, that isn't helpful. We have our reasons, otherwise it wouldn't have started in the first place. No one sat down and said, "Hmm... how best can we anger those MinGW guys?" It came out of necessity for a variety of reasons, and you'd understand that if you approached this whole thing differently. Until you learn how to properly ask the right questions (things like, "Kai, can you explain why you forked a new project? I don't understand, and I'd like to help.") until you learn how to respect the other people involved... well, work can't just stop. We found a place where we can work unconstrained, and hopefully at some point in the future, everything else can be resolved. Until then, please rethink how you are approaching this. |