简体   繁体   English

g++:无法执行'DIRECTORY/collect2.exe':CreateProcess:没有这样的文件或目录

[英]g++ :cannot execute ‘DIRECTORY/collect2.exe’:CreateProcess: No such file or directory

When I compile c++ and c files together with the following command:当我使用以下命令编译 c++ 和 c 文件时:

g++ io.c *.cpp -o main  -D__STDC_FORMAT_MACROS

error occurs:发生错误:

g++.exe: fatal error:cannot execute ‘C:/TDM-GCC-32/bin/../libexec/gcc/mingw32/9.2.0/collect2.exe’: CreateProcess: No such file or directory

And in fact,the collect2.exe exists in the correct directory.实际上, collect2.exe存在于正确的目录中。 I've tried all the solutions provided online, but no one worked.(etc. set/clear environment values,try other versions of mingw32...) The only reason I could think up is that the g++.exe uses / in directories, and windows uses \ instead.我已经尝试了在线提供的所有解决方案,但没有一个有效。(等设置/清除环境值,尝试其他版本的 mingw32 ...)我能想到的唯一原因是g++.exe在目录中使用/ , 而 windows 使用\代替。 So is there any other solutions for the error?那么这个错误还有其他解决方案吗?

LeafFourth identified this for me in this posting: https://github.com/kriscross07/atom-gpp-compiler/issues/26 LeafFourth 在这篇文章中为我确定了这一点: https://github.com/kriscross07/atom-gpp-compiler/issues/26

LeafFourth commented on Mar 23
I have experienced this problem before. The root cause is an exe file was unziped failed with the size zero. I tried another unzip tool to solved it.

For the problem, to know how it happened is important:
CreateProcess is a API to create a process, so the error indicated that the image file used to create the process may not exist.

How to solve it:
Add "-v" flags to run gcc/g++ to compile and then, the verbose log shows. We can find which file not exists. If nothing goes wrong, we can just run the last command in the verbose log with flag "-v" to continue to check recursively.

How I resolved this.我是如何解决这个问题的。

a.一个。 add -v to the compile command:将 -v 添加到编译命令:
c:\Programs\gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf\bin\arm-none-linux-gnueabihf-gcc test5.c -o newlybuiltFile.out -v c:\Programs\gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf\bin\arm-none-linux-gnueabihf-gcc test5.Z4A8A08F09D37B7379v5364903F新建44A8A08F09D37B7379v5364903F

Note: test5.c was a simple main() with no functions.

output was messy, finally ending in 

    c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../libexec/gcc/arm-none-linux-gnueabihf/9.2.1/collect2.exe -plugin c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../libexec/gcc/arm-none-linux-gnueabihf/9.2.1/liblto_plugin-0.dll -plugin-opt=c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../libexec/gcc/arm-none-linux-gnueabihf/9.2.1/lto-wrapper.exe -plugin-opt=-fresolution=C:\Users\pops\AppData\Local\Temp\ccTNEjZv.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=c:\programs\gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf\bin\../arm-none-linux-gnueabihf/libc --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X -m armelf_linux_eabi -o test5.out c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../arm-none-linux-gnueabihf/libc/usr/lib/crt1.o c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../arm-none-linux-gnueabihf/libc/usr/lib/crti.o c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/9.2.1/crtbegin.o -Lc:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/9.2.1 -Lc:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../lib/gcc -Lc:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/9.2.1/../../../../arm-none-linux-gnueabihf/lib -Lc:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../arm-none-linux-gnueabihf/libc/lib -Lc:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../arm-none-linux-gnueabihf/libc/usr/lib C:\Users\pops\AppData\Local\Temp\ccjF1go9.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/9.2.1/crtend.o c:/programs/gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf/bin/../arm-none-linux-gnueabihf/libc/usr/lib/crtn.o
    collect2.exe: fatal error: CreateProcess: No such file or directory
    compilation terminated.
    

b.湾。 I verified all of the files listed - checked the path and saw their existance.我验证了所有列出的文件 - 检查了路径并看到了它们的存在。 NOTE: initially, I did not really look at the file size (I typically do not display it)注意:最初,我并没有真正查看文件大小(我通常不显示它)

c. c。 note that the *.DLL files also call other functions/libraries.请注意,*.DLL 文件也调用其他函数/库。 So you may not be seeing everything.所以你可能没有看到一切。 this could be a really big task to verify all files.验证所有文件可能是一项非常艰巨的任务。

d. d。 I finally noticed that my primary bin files did not install properly.我终于注意到我的主 bin 文件没有正确安装。 see image.见图片。

clearly not a good install显然不是一个好的安装

>   proper install should have files with size > 0 Kbytes.

improved install for my primary bin executables改进了我的主要 bin 可执行文件的安装

e. e. solution was to re-install the MinGW tools.解决方案是重新安装 MinGW 工具。 The simple compile now works properly.简单的编译现在可以正常工作。

Well, I finally successfully compile the source files with Visual Studio .好吧,我终于成功地用Visual Studio编译了源文件。 It's not an answer for this question but it's a way out if no other solutions found.这不是这个问题的答案,但如果没有找到其他解决方案,这是一条出路。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM