arm-none-eabi-g ++:错误:CreateProcess:没有这样的文件或目录

时间:2019-09-19 14:12:06

标签: c++ windows makefile mingw createprocess

我在Windows上运行的arm-none-eabi-g ++编译器有问题。 当我在Ubuntu上运行makefile时,一切正常。

Makefile目标在Windows上失败,并显示错误

arm-none-eabi-g++: error: CreateProcess: No such file or directory

我在Windows上使用MingGW。 MinGW,make和G ++位置已添加到Win PATH。

两个操作系统上的编译器和make版本相同。

Ubuntu

getconf ARG_MAX
2097152

arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

带有MinGW的Windows 10

getconf ARG_MAX
32000

arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make --version
GNU Make 4.1
Built for i686-w64-mingw32
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

更多信息

这是我的makefile目标之一的样子

$(PROJECT).o: $(PROJECT).cpp
    @echo start of $(@F)
    $(CPP) $(CC_FLAGS) @./.symbols.txt -std=gnu++11 -fno-rtti @./.includes.txt -o $@ $<
    @echo end of $(@F)

有趣的是,只有.symbols.txt和.includes.txt的总和小于32k时,Windows构建才能正常工作。因此,看起来好像取决于ARG_MAX大小(在MINGW 32k上),但事实并非如此。因为同一makefile中的另一个目标看起来像

$(PROJECT).elf: $(SYS_OBJECTS)
    $(file > .sys_objects.txt, $(SYS_OBJECTS))
    $(LD) $(LD_FLAGS) -T$(LINKER_SCRIPT) $(LIBRARY_PATHS) -o $@ @./.sys_objects.txt $(LIBRARIES) $(LD_SYS_LIBS) $(LIBRARIES) $(LD_SYS_LIBS)

尽管sys_objects.txt的大小约为90k,但它在Windows上仍能很好地工作。

$(LD)和变量$(CPP)变量都设置为arm-none-eabi-g ++。

我注意到的另一件事是Windows上的某些操作在g ++命令的末尾添加了一个文件,例如C:\ Users \ user \ AppData \ Local \ Temp \ ccQWU5K6.s(无论是否失败)。我不知道这是哪里来的(也许是一些MINGW支持的论点?)。

有没有人知道为什么即使另一个目标在使用大参数的情况下也能正常工作,但在Windows上使用大于32k的参数构建会失败?也许是巧合。

0 个答案:

没有答案