From: Roland S. <rol...@ch...> - 2008-03-23 12:45:45
|
With the mingw 3.4.5 release it was possible to invoke the compiler just by calling with an absolute path without the need to set up the path variable before. This is not true anymore for 4.2.1. I get a CreateProcess: No such file or directory error message instead. Has this been changed intentionally? ( I am talking about using mingw from the CMD.EXE without MSYS. ) Any hints appreciated! -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: JonY <10...@gm...> - 2008-03-23 13:04:13
|
Roland Schwarz wrote: > With the mingw 3.4.5 release it was possible to invoke > the compiler just by calling with an absolute path without > the need to set up the path variable before. > > This is not true anymore for 4.2.1. I get a CreateProcess: > No such file or directory error message instead. > Has this been changed intentionally? > > ( I am talking about using mingw from the CMD.EXE without > MSYS. ) > > Any hints appreciated! > Hi, strangely, mine works, and I don't have them in path either. Try adding -v to the command line. There should be clues there. |
From: Roland S. <rol...@ch...> - 2008-03-23 13:16:43
|
JonY wrote: > Hi, > strangely, mine works, and I don't have them in path either. > > Try adding -v to the command line. There should be clues there. Already did so. Before I discovered the behaviour I had the cygwin in my PATH. The as was picked up from there. Can you try with an (almost) empty PATH? Say just C:\mingw-4.2.1\bin;C:\Windows;C:\Windows\system32 in it? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: Greg C. <gch...@sb...> - 2008-03-23 14:33:59
|
On 2008-03-23 12:45Z, Roland Schwarz wrote: > With the mingw 3.4.5 release it was possible to invoke > the compiler just by calling with an absolute path without > the need to set up the path variable before. > > This is not true anymore for 4.2.1. I get a CreateProcess: > No such file or directory error message instead. It's best to paste the exact error message here. What version of ms windows are you using? Is it "vista"? > Has this been changed intentionally? > > ( I am talking about using mingw from the CMD.EXE without > MSYS. ) Not reproduced here with ms windows "xp": C:\tmp>PATH '' C:\tmp>PATH PATH='' C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc -dumpversion 4.2.1-sjlj C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc hello.c C:\tmp>a.exe hello, world! |
From: Roland S. <rol...@ch...> - 2008-03-23 16:00:33
|
Greg Chicares wrote: > What version of ms windows are you using? Is it "vista"? No, XP. (32 bit) > Not reproduced here with ms windows "xp": > > C:\tmp>PATH '' > > C:\tmp>PATH > PATH='' > > C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc -dumpversion > 4.2.1-sjlj > > C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc hello.c > > C:\tmp>a.exe > hello, world! Hmm, I am trying to compile c++... and this is what I get: C:\TMP> PATH=C:\Windows;C:\Windows\system32 C:\TMP> C:\Programme\mingw\bin\g++-sjlj hello.cpp g++-sjlj: CreateProcess: No such file or directory C:\TMP> But the above works if I put the following to PATH: PATH=C:\Windows;C:\Windows\system32;C:\Programme\mingw\bin Any ideas? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: Roland S. <rol...@ch...> - 2008-03-23 16:32:49
|
Roland Schwarz wrote: > Hmm, I am trying to compile c++... and this is what I get: > > C:\TMP> PATH=C:\Windows;C:\Windows\system32 > > C:\TMP> C:\Programme\mingw\bin\g++-sjlj hello.cpp > g++-sjlj: CreateProcess: No such file or directory > > C:\TMP> > > But the above works if I put the following to PATH: > PATH=C:\Windows;C:\Windows\system32;C:\Programme\mingw\bin > > Any ideas? The same is true for *.c for me :-( What could I am be doing wrong? I am using the technology preview pre-builts from source-forge. Is this not a good idea? Should I try to build it myself? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: JonY <10...@gm...> - 2008-03-23 16:27:06
|
Roland Schwarz wrote: > > JonY wrote: >> Hi, >> strangely, mine works, and I don't have them in path either. >> >> Try adding -v to the command line. There should be clues there. > > Already did so. Before I discovered the behaviour I had the cygwin > in my PATH. The as was picked up from there. > > Can you try with an (almost) empty PATH? > Say just C:\mingw-4.2.1\bin;C:\Windows;C:\Windows\system32 > in it? > > Hi, I never had MinGW bin directory in my path before. "echo main(){}|C:\MingW\bin\gcc -xc - && .\a.exe" works fine here. I think there was an issue with the precompiled gcc 4 from sourceforge downloads trying to pick up the back end drivers hard coded at C:\MingW\libexec\, but that doesn't seem to be the case. Can you use -v and determine what g++ is failing to start? |
From: Roland S. <rol...@ch...> - 2008-03-23 16:38:28
|
JonY wrote: > I think there was an issue with the precompiled gcc 4 from sourceforge > downloads trying to pick up the back end drivers hard coded at > C:\MingW\libexec\, but that doesn't seem to be the case. Ah, I see. I am using just this download. > Can you use -v and determine what g++ is failing to start? as is the last I can see before the error. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: Keith M. <kei...@us...> - 2008-03-23 17:02:19
|
On Sunday 23 March 2008 16:38, Roland Schwarz wrote: > > I think there was an issue with the precompiled gcc 4 from > > sourceforge downloads trying to pick up the back end drivers hard > > coded at C:\MingW\libexec\, but that doesn't seem to be the case. > > Ah, I see. I am using just this download. > > > Can you use -v and determine what g++ is failing to start? > > as > is the last I can see before the error. Have you installed binutils? And mingw-runtime and w32api? All in the same prefix as the 4.2.1 compiler? I don't recall reports of an issue with `C:/mingw' being hardcoded, but the entire tool chain needs to located relative to the compiler driver itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix. Regards, Keith. |
From: Roland S. <rol...@ch...> - 2008-03-23 17:25:17
|
Keith Marshall wrote: > Have you installed binutils? Yes. > And mingw-runtime Yes. > and w32api? Yes. > All in the > same prefix as the 4.2.1 compiler? Yes. > > I don't recall reports of an issue with `C:/mingw' being hardcoded, but > the entire tool chain needs to located relative to the compiler driver > itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the > tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix. Have you seen the post from: John E. / TDM td...@td... ? I used his idea of the work-around. I created a symlinked directory of the bin like so: CD path-to-mingw MKDIR mingw32 CD mingw32 LINKD bin path-to-mingw\bin This works as John said. The binutil tools now are correctly picked up. So it look like it simply would be necessary to add the bin dir to the searched directories. Hopefully someone in charge of this won't forget about .... Thank you, it works for me now :-) -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:rol...@ch... ________| http://www.blackspace.at |
From: JonY <10...@gm...> - 2008-03-23 17:44:36
|
Roland Schwarz wrote: >> I don't recall reports of an issue with `C:/mingw' being hardcoded, but >> the entire tool chain needs to located relative to the compiler driver >> itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the >> tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix. > > Have you seen the post from: > John E. / TDM td...@td... ? > > I used his idea of the work-around. I created a symlinked directory of > the bin like so: > > CD path-to-mingw > MKDIR mingw32 > CD mingw32 > LINKD bin path-to-mingw\bin > > This works as John said. The binutil tools now are correctly picked up. > > So it look like it simply would be necessary to add the bin dir to the > searched directories. Hopefully someone in charge of this won't forget > about .... > > Thank you, it works for me now :-) > > Hi, It seems this is the hard code path problem, sort of anyway. I did a bit of tests and was able to reproduce Roland's problem. It looks as if the precompiled gcc was looking for binutils at <drive>:\MinGW\bin, where drive is the drive letter gcc is residing on. It should have been using relative paths. Placing a mingw directory with binutils made as.exe work again. I had a quick looked around gcc's code but wasn't able to determine how gcc calls support programs. Any ideas? |
From: John E. / T. <td...@td...> - 2008-03-23 18:11:31
|
JonY wrote: > I had a quick looked around gcc's code but wasn't able to determine how > gcc calls support programs. Any ideas? See process_command() in gcc/gcc.c, starting after line 3939 in the 4.2.1-2 sources. -John E. / TDM |
From: John E. / T. <td...@td...> - 2008-03-23 16:48:20
|
Roland Schwarz wrote: > With the mingw 3.4.5 release it was possible to invoke > the compiler just by calling with an absolute path without > the need to set up the path variable before. > > This is not true anymore for 4.2.1. I get a CreateProcess: > No such file or directory error message instead. > Has this been changed intentionally? I can confirm this behavior. MinGW's release of GCC 3.4.5 contains a large amount of local patching, some of which I believe addresses issues like this of finding tools relative to the driver executables. If you add "-v" to the command line, I expect you'll see that the error message immediately follows a call to "as" (the assembler). I imagine that as most of the local patches were ported to the mainline sources, this small part didn't quite survive intact. Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`, it should be fairly obvious what's happening. For the programs search directories, there is no path corresponding to the root "bin" directory, which is where your binutils executables live. There is, however, a path corresponding to "path-to-mingw\mingw32\bin", which is an alternate location for the binutils tools. For a workaround, you can try copying the binutils executables there. (Depending on which binutils release you have, there may already be some empty files there -- I have seen this packaging bug with the 2.18.50 release.) Cheers, John E. / TDM |
From: Keith M. <kei...@us...> - 2008-03-25 18:44:35
|
Summarising the follow-up discussion, and taking the opportunity to add my own two pennyworth:-- On Sunday 23 March 2008 12:45, Roland Schwarz wrote: > With the mingw 3.4.5 release it was possible to invoke > the compiler just by calling with an absolute path without > the need to set up the path variable before. > > This is not true anymore for 4.2.1. I get a CreateProcess: > No such file or directory error message instead. > Has this been changed intentionally? No. Assuming that you are using one of our pre-built binary packages for binutils-2.18.50, the follow-up discussion suggests that this is an inadvertent packaging bug; thanks for alerting us. On Sunday 23 March 2008 16:47, John E. / TDM wrote: > Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`, > it should be fairly obvious what's happening. For the programs search > directories, there is no path corresponding to the root "bin" > directory, which is where your binutils executables live. There is, > however, a path corresponding to "path-to-mingw\mingw32\bin", which > is an alternate location for the binutils tools. For a workaround, > you can try copying the binutils executables there. (Depending on > which binutils release you have, there may already be some empty > files there -- I have seen this packaging bug with the 2.18.50 > release.) On Monday 24 March 2008 01:07, Danny Smith wrote: > [path-to-mingw\mingw32\bin] is not the alternate location. This is > the first place the compuiler looks. That is where binutils package is > supposed to install them. On Monday 24 March 2008 02:48, John E. / TDM wrote: > That's good to know. Does this indicate a packaging bug in the > binutils 2.18.50 tech preview, since they were built with a different > target triplet (i686-pc-mingw32)? Yes. I do not want to point any "finger of blame", for witch hunts serve no useful purpose. The underlying cause of the problem lies in the complete absence of any agreed and formally documented policy on how the MinGW packages should be prepared for release; for that, the project team, as a whole, is collectively responsible. > If not, I think it should at least merit a warning to the effect > of "since this build uses a newer target triplet, you have to have the > bin directory in your PATH". It *is* a packaging bug. For those afflicted by it, this is a possible workaround, although perhaps not the most effective one. On Monday 24 March 2008 12:12, JonY wrote: > I noticed that some packages using autotools which would fail when > the mingw provided gcc 3.4.5 which was targeted at mingw32 and a > newer user built binutils which was targeted at i686-pc-mingw32 was > used. It was looking for the ld linker in the wrong place. As Danny pointed out, the correct installation path, as *he* specified it for his MinGW-GCC builds is /path/to/mingw/mingw32/{bin,lib}; if we accept that as the standard, (and it seems reasonable, and as good as any to me), then... > The newer binutils executables would reside in /mingw/bin and > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32 > containing the older binutils was removed. the implicit `i686-pc-mingw32' target specification used when building the binutils-1.18.50 binary package is only the apparent cause of the packaging bug; the real underlying cause is lack of an appropriately documented packaging methodology. The reason this didn't show up, until you removed the older binutils from /path/to/mingw/mingw32/{bin,lib} was that GCC was actually *using* these older tools; you may have thought you had installed the newer binutils, but you were never using it. > Problem fixed by using junction points to link mingw32 and > i686-pc-mingw32 together. This is another possible workaround, but I wouldn't classify it as a "fix"; the only ultimately acceptable "fix" is to rebuild the binary package, with the appropriately agreed target specification, repackage and replace the defective binary release tarballs on the SF download site, and mirrors. For those afflicted by this bug, a further possible workaround would be to physically *move* everything from /path/to/i686-pc-mingw32/{bin,lib} into the corresponding /path/to/mingw/mingw32/{bin,lib} trees, in place of any similarly named component files which are already there; of the three workarounds suggested, this would be my preferred choice, as I would expect it to restore everything to the state it should be in, to conform with Danny's previous de-facto build standard. On Monday 24 March 2008 11:51, Earnie Boyd wrote: > I thought the target was supposed to be stated without the triplet, > meaning --target=mingw32, for the distributed binaries since i686-pc > has little relevance to MinGW. I agree that `i686-pc', (as such, or with any other CPU designation), has little relevance for MinGW; formalising the de-facto use of just `mingw32' here makes sense to me. It does seem somehow anomalous to be required to specify *any* form of `--target=target_alias', for self-hosted (native) builds, or even of crossed-native builds, of any package; indeed, it would be unnecessary for building of the entire tool chain as a single integrated package. In the particular case of MinGW, however, it *is* necessary, to allow for mixing and matching of component packages at different release points, and from different maintainers. This particular problem has arisen because the binutils-2.18.50 tech preview has been built with no `--target=target_alias' specified, on an i686 host, so target_alias has been implicitly determined, by running config.guess, and the resultant `i686-pc-mingw32' does not conform to the de-facto mingw32 standard. There is a lesson to be learnt here; let's not ignore it. We should take this discussion to the developers' list, where we formally agree, and document, a standard procedure for building MinGW packages for public release, so that future maintainers can understand the reasons for, and continue to follow, the standards in use today. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-03-26 21:01:12
|
On Tuesday 25 March 2008 18:45, Keith Marshall wrote: > For those afflicted by this bug, a further possible workaround would > be to physically *move* everything from > /path/to/i686-pc-mingw32/{bin,lib} into the corresponding > /path/to/mingw/mingw32/{bin,lib} trees, in place of any similarly > named component files which are already there; of the three > workarounds suggested, this would be my preferred choice, as I would > expect it to restore everything to the state it should be in, to > conform with Danny's previous de-facto build standard. I may have spoken too soon here. I notice that the specified target alias, whether specified implicitly or explicitly, is hardcoded into the various tools, so simply relocating them may not have the desired effect. Sorry, if this has inconvenienced anyone. Regards, Keith. |
From: NightStrike <nig...@gm...> - 2008-03-26 04:16:29
|
On 3/25/08, Keith Marshall <kei...@us...> wrote: > > The newer binutils executables would reside in /mingw/bin and > > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32 > > containing the older binutils was removed. > > the implicit `i686-pc-mingw32' target specification used when building > the binutils-1.18.50 binary package is only the apparent cause of the > packaging bug; the real underlying cause is lack of an appropriately > documented packaging methodology. > > Problem fixed by using junction points to link mingw32 and > > i686-pc-mingw32 together. > > This is another possible workaround, but I wouldn't classify it as > a "fix"; the only ultimately acceptable "fix" is to rebuild the binary > package, with the appropriately agreed target specification, repackage > and replace the defective binary release tarballs on the SF download > site, and mirrors. > On Monday 24 March 2008 11:51, Earnie Boyd wrote: > > I thought the target was supposed to be stated without the triplet, > > meaning --target=mingw32, for the distributed binaries since i686-pc > > has little relevance to MinGW. > > I agree that `i686-pc', (as such, or with any other CPU designation), > has little relevance for MinGW; formalising the de-facto use of just > `mingw32' here makes sense to me. If you want to be able to have x86_64 support merge back in to mingw, then supporting the CPU designation is advantageous. To that end, supporting the gnu standard canonicalization fully is advantageous. With the way I build things, I can have both i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the same root directory structure. However, the requirement of the lone "mingw32" directory makes that difficult. |
From: Keith M. <kei...@us...> - 2008-03-26 20:56:37
|
On Wednesday 26 March 2008 04:16, NightStrike wrote: > If you want to be able to have x86_64 support merge back in to mingw, > then supporting the CPU designation is advantageous. Can we please restrict this discussion to the developers' list for now. When we have agreed our preferred policy, and compiled a draft spec, we will come back here, for comment from the wider user community. Thanks, Keith. |