インストールディレクトリ(E:\MinGW\bin
)外でGCCを実行しようとすると、このエラーが発生します。
それで、私がE:\code
にいて、one.c
というファイルを持っているとしましょう。実行中:gcc one.c -o one.exe
はこのエラーを表示します:
gcc: CreateProcess: No such file or directory
唯一の回避策は、インストールディレクトリに移動し、そこからgccを実行し、他のすべてのパスを指定することです。私の環境変数Path
にはE:\MinGW\bin
が含まれています。
この問題を修正するための提案はありますか? Windows XP SP3を実行しています。
Migwinのウィンドウで環境変数を設定した後、再起動する必要があることを具体的に伝えました。
Code :: Blocks wiki によると、C:\MinGW\libexec\gcc\mingw32\MinGW-Version
をPATH
に。再起動する必要はありませんが、最新のPATH
設定を取得するために別のターミナルを開く必要があります。
MinGW-w64の場合、<mingw install directory>\libexec\gcc\x86_64-w64-mingw32\4.7.0\
C++コンパイラをインストールしていないために、同様の問題が発生しました。私の場合、Python拡張子の.cppファイルをコンパイルしていましたが、コンパイラは最初にc:\ mingw\bin\gcc.exeとして呼び出されます。
内部的には、gcc.exeは.cppファイルのコンパイルを求められたことに気付きます。 g ++。exeを呼び出して、同じエラーメッセージで失敗します。
gcc.exe:CreateProcess:そのようなファイルまたはディレクトリはありません
この問題が発生しました。
私の場合、問題はGCCのパッケージをダウンロードするときの問題が原因でした。 mingw-getプログラムはダウンロードを完了したと考えましたが、完了しませんでした。
GCCをアップグレードしたかったので、mingw-getを使用して新しいバージョンを取得しました。何らかの理由で、mingw-getは特定のファイルのダウンロードが終了したと考えましたが、そうではありませんでした。ファイルを抽出しようとしたとき、エラーが発生したと思います(気にすることすらしませんでした-"mingw-get update && mingw-get install mingw32-gcc"を実行して、そのまま残しました)。
解決するために、「mingw-get remove mingw32-gcc」を実行してgccを削除し、mingwキャッシュフォルダー(「C:\ MinGW \」にあるパッケージファイル(mingw-getが完全にダウンロードしなかったもの)も削除しました。私のシステムでvar\cache\mingw-get\packages ")、インストールコマンドを再度実行しました。 GCCの欠落部分をダウンロードしてインストールしました(パッケージgcc-coreを完全にはダウンロードしていませんでした)。
これで私の問題は解決しました。
興味深いことに、mingw-getは、キャッシュフォルダーのパッケージファイルを削除し、パッケージmingw32-gccを削除した後でも、gcc-coreのダウンロードを続行できるほどスマートでした。
もっと根本的な問題は、gcc-coreファイルがインストールされていないので、cc1がそこになかったことだと思います。そして、gccはcc1を使用します。 gccがcc1を開始しようとしたときに、既存のファイルのパスではないcc1のパスを渡すCreateProcessを使用したと思います。したがって、エラーメッセージ。
つまり、これはwhatファイルが見つからないことを通知しないため、愚かなエラーメッセージです。
冗長フラグgcc -v
を指定してコマンドを再度実行し、gccの現在の状態を確認します。
私の場合、cc1plus
を呼び出そうとしていました。私はチェックしました、私はそれを持っていません。 mingwのC++コンパイラをインストールしてからインストールしました。
私はまったく同じ問題を抱えていました。
PATH
を再確認した後、Mingw
(64ビット)とCygwin
(32ビット)の両方をインストールしたことに気付きました。問題は、Mingw
とCygwin
の両方がg++
。
Cygwin
のパスを非アクティブ化することにより、エラーが消えました。
Mingwインストールへのリンクを使用してCygwinから実行しようとすると、同じエラーメッセージが表示されていました。
http://www.mingw.org/wiki/FAQ からmingw32-make-3.80.0-3.exeの同じインストールを使用し、スタート->プログラム->からmingw Shellオプションを使用WinXP SP3とgccは正常に動作しています。
同様の問題が発生しました。最初は、GCC binフォルダーをシステムパスに追加しても問題は解決しませんでした。私は2つの解決策を見つけました。
最初の方法は、MinGWインストールのルートにあるmingwbuilds.batにあるバッチファイルを実行することでした。 (明らかに)GCCを実行するように正しく構成されたコマンドプロンプトを起動します。 2番目は、ユーザーパス変数に追加したGCCインストールbinフォルダーから二重引用符を削除することでした。インストールbinパスを二重引用符で囲まないバッチファイルに気付いた後、これを試しました。
追加の詳細
(-v出力による)起動していないさまざまな実行可能ファイルを見つけようとして、インストールフォルダーツリーを参照しているときに誤ってバッチファイルを見つけました。 MinGW wikiでいくつかの情報を見つけました http://www.mingw.org/wiki/Getting_Started 、注意および環境設定セクションで、MinGWインストーラーがシステムをセットアップしない理由を示しますまたはインストールフォルダを含めるユーザーパス。これらは、バッチファイルがWindowsプロンプトからGCCを実行するのに適したコマンドプロンプトを起動することを意図していることを確認しているようです。
私はこの同じ問題を抱えていましたが、提案された修正はどれもうまくいきませんでした。したがって、これは古いスレッドですが、他の誰かがこのスレッドをGoogleで見つけた場合(私のように)解決策を投稿することも考えています。
私にとっては、MinGWをアンインストールするか、MinGWフォルダーを削除して、再インストールする必要がありました。再インストール後、それは魅力のように機能します。
この問題は、Mingw GCCでコンパイルするときに、小文字stuff.cではなく大文字の接尾辞stuff.Cを使用するためです。たとえば、次のような場合:
gcc -o stuff stuff.C
次のメッセージが表示されます:gcc: CreateProcess: No such file or directory
しかし、これを行う場合:
gcc -o stuff stuff.c
その後、動作します。理由がわかりません。
私は同じ問題を抱えていましたが、現在リストされている解決策はどれも最初の試行では役に立ちませんでした。
-v
オプションは、追加の手がかりを与えませんでした。
問題の根本を見つけることができるように ProcMon に頼らなければなりませんでした。
g++
プロセスファイルアクティビティをダンプすると、さまざまなパスでcc1plus
実行可能ファイルを見つけようとする多数の試みが明らかになりました。それらの中には、古いGCCバージョンへのパスがありました。
しかし、その古いバージョンは別のフォルダーにあり、実行しようとした新しいバージョンからはまったく参照されませんでした。
最後に、システム%PATH%環境変数で廃止されたパスが見つかりました。それを削除した後、新しいバージョンはエラーなしで動作し始めました。
私は非常に長いパスを持っていて、どこかにファイル(gcc.exeではありません)がありますが、そのgcc.exeがパスからアクセスしている別のファイルがあります。
だから私はパスをクリアしたとき、それは働いた
_C:\MinGW>cd bin
C:\MinGW\bin>where gcc.exe
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe
_
^^そこからgccを実行すると、間違いなくming gcc.exeが実行されます
_C:\MinGW\bin>type file6.c
#include<stdio.h>
void main()
{
int num1,num2;
scanf("%2d %4d",&num1,&num2);
printf("a=%d b=%d",num1,num2);
scanf("%d",&num1);
//flushall();
printf("c=%d",num1);
}
_
それをコンパイルすると、このエラーが発生しました
_C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
_
私のパスは巨大でした
_C:\MinGW\bin>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\P......
_
C:\ MinGW\bin>パス| grep -io "ming"
そこには何もありませんでした。
C:\ MinGW\bin> echo MING | grep -io "ming" MING
(そして、grepが動作することは確かです。パスはそこにありませんでした)
私の道を完全にクリアして、それが機能するようになりました!
_C:\MinGW\bin>set PATH=
C:\MinGW\bin>gcc file6.c
C:\MinGW\bin>
_
そのため、衝突の原因となったPATHの内容はまだ明確ではありません。どのディレクトリ、どのファイル。
更新-
上記は私には正しいように思えますが、追加するのは、通常、現在のディレクトリが優先されるため、パス衝突の初期段階の何かの単純なケースでもありません。そして、gcc --versionが競合するディレクトリ内の1つではなく、ming 1を実行していることを示す限り、ここで実行します。そのため、競合するディレクトリがパスにある場合)、おかしいことがあります)、。\ gccを実行するか、パスの先頭に_.
_を追加するか、競合するディレクトリの前に_c:\MinGW\bin
_を追加する必要がありますパスで。これは_C:\MinGW\bin
_にいるときでも当てはまりますが、それは奇妙です。また、エラーが発生した場合は、Mingのgccを実行していますが、プロセスモニターからわかるように、(何らかの理由で)競合するディレクトリも調べています。より多くの答えがここにあるかもしれません http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista ここで非常に支持された答えで言及されたリンクに
Ming32ビットです。
Ming 64bitを見ると、おそらく同じ問題がありますが、興味深いことに、実際にはbinディレクトリをパスのタルトに(賢明に)置くbatファイルが付属しています。そして、それはMing gccを適切に実行する標準的な方法のようです。
Code :: blocks IDE(賢明にも)パスの先頭にbinディレクトリを置きます。環境変数を表示するCプログラムを実行すると、それがわかります。
「男に魚を与え、1日に餌を与え、男に魚を教え、週末全体にわたって彼を追い払う」という流れで、
g ++ --help
-vコンパイラーによって呼び出されたプログラムを表示します
偽のパスの出力を調べます。私の場合、元のコマンド:
g ++ -v "d:/UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"
この小さな宝石を含む生成された出力:
-iprefix c:\ olimexods\yagarto\arm-none-eabi\bin\../ lib/gcc/arm-none-eabi/4.5.1 /
「そのようなファイルまたはディレクトリがありません」というメッセージを説明します。
「../lib/gcc/arm-none-eabi/4.5.1/」セグメントは、組み込みの仕様に基づいています。
g ++ -dumpspecs
この問題は、異なるバージョンのプログラムがある場合に発生する可能性があります。
たとえば、1年前のgcc
があり、C++ソースコードをコンパイルするとします。 mingw-get
を使用してg++
をインストールすると、gcc
とg++
のバージョンが突然異なるため、この状況に陥る可能性が高くなります。
mingw-get update
およびmingw-get upgrade
を実行すると、この問題は解決しました。
追加 E:\MinGW\bin
をPATH
変数に。
投稿は古いですが、2015/02/13のmingw32バージョン4.8.1で同じ問題が発生しました。 Eclipse CDTを使用したコンパイルは、このメッセージで失敗しました。 -vオプションを使用してコマンドラインから試行することもできませんでした。また、cc1plus実行可能ファイルが欠落していました。
原因:mingw32サイトからコマンドラインとグラフィカルインストーラーをダウンロードしました。これを使用して、mingw32の初期インストールを行いました。 GUIを使用して、基本ツールを選択し、cコンパイラとc ++コンパイラの両方を選択しました。
このインストーラーは、32ビットc ++コンパイラーの不完全なインストールを行いました。 g ++およびcppファイルはありましたが、cc1plus実行可能ファイルはありませんでした。インストーラーはすべてがインストールされていると仮定したため、「更新」を実行しようとして失敗しました。
修正するには、これらのサイトを見つけました: http://mingw-w64.sourceforge.net/http://sourceforge.net/projects/mingw-w64/ ダウンロードしてこの「オンラインインストール」を実行しました。案の定このファイルには欠落しているファイルが含まれていました。 PATH変数を変更し、g ++実行可能ファイルを含む「bin」フォルダーをポイントしました。再起動しました。 64ビットEclipseをインストールしました。 Eclipseを開き、「Hello World」c ++プログラムを適切にコンパイル、実行、デバッグしました。
注:64ビットインストーラーはデフォルトでUNIX設定になっているようです。インストーラーがOSを判別できないのはなぜですか?必ず変更してください。
私はこれに対処するために全体の夜を過ごしました。これが誰かを助けることを願っています。
同じ問題がありました。
MinGW(パッケージmingw32-gcc-g ++)を介してg ++コンパイラーを既にインストールしていましたが、Cコンパイラーが必要だったため、mingw-get-setup.exeを実行してインストールできましたmingw32-baseパッケージ、Cコンパイラを使用するパッケージ。
ああ! gccを使用してコンパイルすると、このエラーが発生しました。
gcc:エラー:createprocess:そのようなファイルまたはディレクトリはありません
私がやったことは、まだMinGW Installation Managerを使用して、CとC++コンパイラパッケージ、つまりmingw32-baseとmingw32-gcc-g ++を削除し、Cも削除しました:\ MinGWディレクトリ自体。それから、インストールされたmingw-get-setup.exeを再実行し、mingw32-baseをインストールしました。
私は同じ問題を抱えていました(cygwinを実行しています)
Cygwin.batを介してシェルを起動することは役に立ちませんでしたが、MingWShellを介してシェルを起動することは役に立ちました。理由は定かではありませんが、cygwinが実行中のスクリプトと基礎となるファイルシステムの間に置く余分なレイヤーと関係があると思います。
仮想環境のcygwin内からpip installを実行して、Django sentry ..
MinGWにはいくつかのリリースディストリビューションがあるようです。どちらを試しましたか?記録のために、私はOPとまったく同じ問題に遭遇し、私が得たディストリビューションはTDM-GCC 4.5.1からでした。
MinGWディストリビューション here がはるかに良く機能し、正しく設定されているようです。したがって、この遅延した「createprocess-no-such-file-or-directory」エラーが発生して動作しない場合は、既存のMinGWをアンインストールして、代わりにリンクしたものを試してください。
私は同じ問題を抱えていて、結果なしですべてを試しましたが、私にとって問題を修正したのは、PATH変数のライブラリパスの順序を変更したことです。私はcygwinと他のいくつかのコンパイラーを持っているので、おそらくそれらの間に何らかの衝突がありました。私がしたことは、C:\ MinGW\binを置くことでした。他のすべてのパスの前に最初のパス、それは私のために問題を修正しました!
(元の問題を参照)
今日のバージョンのmingw
(投稿日を参照)
私がしなければならなかったのは、実行したのと同じシェルにパスを設定することでしたgcc
。
1時間かけて、DOS variables
...
A:> set PATH=C:\MinGW\bin\;
C:\Program Files\ImageMagick-6.8.0-Q16\;
C:\WINDOWS\system32\;C:\WINDOWS\;C:\WINDOWS\System32\Wbem\;
C:\WINDOWS\system32\WindowsPowerShell\v1.0\;
C:\Program Files\QuickTime\QTSystem\
A:> gcc hi.c
環境変数にユーザー変数を入れる代わりに、システム変数にパスを入れてください。
MinGW-w64を使用しており、<install path>\bin
のコマンドにはすべて奇妙なプレフィックスが付いていたため、このエラーメッセージが表示されていました。 <install path>\bin
ディレクトリではなく、「ターゲットエイリアス」ディレクトリで実行可能ファイルを呼び出そうとしましたが、さらに多くの問題が発生しました。 [〜#〜] faq [〜#〜] によれば、これはノーです。私にとっての解決策は、すべてのプレフィックス付きコマンドへのシンボリックリンクを作成することでした。昇格したコマンドプロンプトを開き、すべての実行可能ファイルに対してmklink gcc.exe x86_64-w64-mingw32-gcc.exe
のようなものを使用しましたが、ビルドが機能するようになりました。