I’ve been getting this error when building on VScode in Windows.
If I build the exact same code in Linux (using command line) it just works out fine.
It happens with PIO 5.0.1 and the latest 5.0.2 dev version. (reinstalled PIO and all its cache and downloaded packages a few times already)
Building in release mode
Compiling .piobuildcustom_beta_ESP8266_4M1MsrcESPEasy.ino.cpp.o
Linking .piobuildcustom_beta_ESP8266_4M1MESP_Easy_mega_20201012_custom_beta_ESP8266_4M1M.elf
collect2.exe: fatal error: CreateProcess: No such file or directory
compilation terminated.
*** [.piobuildcustom_beta_ESP8266_4M1MESP_Easy_mega_20201012_custom_beta_ESP8266_4M1M.elf] Error 1
The strange thing is, it only happens with some of my PIO environments and also depends on some commits I make.
I have been working very hard on converting all my .ino files to .cpp/.h (see: platformio/platformio-vscode-ide#2067 ) and in the process I do see this happen on some of my PIO environments and after a new commit (changing again a few dozen files) it happens on even more environments.
If I checkout an older commit it can be built again in a few environments that failed before.
So it just seems like I’m hitting some resource limit when building in VScode?
In my changes from .ino to .cpp/.h I do try to include as little as possible in .h files an try to only include in the .cpp file.
Only exception is files like ESPEasy_common.h, which are included almost everywhere.
N.B. my environments differ in the used ESP8266/Arduino core library and also the number of «plugins» of my code included in the build.
I created a branch of which the last commit made compiling impossible in VS code for the custom_ESP8266_4M1M environment. https://github.com/TD-er/ESPEasy/tree/build/failing_custom_windows_builds
When going back 1 commit in that branch, it compiles again.
Even building in verbose mode is not giving any clue why it failed to generate the .elf file.
So to summarize:
- Some env. builds in VScode (Windows) suddenly fail after converting some .ino files to .cpp/.h
- Command line build in the terminal of VScode also fails.
- The same code built in Linux (command line) works just fine
- Reverting back to a previous commit makes those envs build again in VScode.
Hi @TD-er ! On Windows the maximum length of the string (including all arguments) passed to CreateProcess() is 32768 characters and it looks like the final linker command exceeds that limit. Please attach here verbose output so I can try to come up with possible workarounds.
Hmm that sounds plausible.
I first made a normal failing build and then a verbose build as it would then just fail on the linker part, right?
Building in release mode
xtensa-lx106-elf-g++ -o .piobuildcustom_ESP8266_4M1MsrcESPEasy.ino.cpp.o -c -fno-rtti -std=c++11 -mtarget-align -fno-exceptions -O2 -Wno-deprecated-declarations -Os -mlongcalls -mtext-section-literals -falign-functions=4 -U__STRICT_ANSI__ -ffunction-sections -fdata-sections -fno-exceptions -Wall -DCONTROLLER_SET_ALL -DNOTIFIER_SET_NONE -DUSES_P001 -DUSES_P002 -DUSES_P004 -DUSES_P027 -DUSES_P028 -DUSES_P036 -DUSES_P045 -DUSES_P049 -DUSES_P052 -DUSES_P056 -DUSES_P059 -DUSES_P081 -DUSES_P082 -DUSES_P085 -DUSES_P100 -DUSES_C016 -DUSES_C018 -DFEATURE_MDNS -DFEATURE_SD -DFEATURE_I2CMULTIPLEXER -DUSE_SETTINGS_ARCHIVE -DPLATFORMIO=50001 -DESP8266 -DARDUINO_ARCH_ESP8266 -DARDUINO_ESP8266_ESP12 -DBUILD_GIT="" -DNDEBUG -DVTABLES_IN_FLASH -DPIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH_LOW_FLASH -DPUYA_SUPPORT=1 -DCORE_POST_2_5_0 -DBEARSSL_SSL_BASIC -DCORE_POST_2_6_0 -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703 -DMQTT_MAX_PACKET_SIZE=1024 -DHTTPCLIENT_1_1_COMPATIBLE=0 -DPLUGIN_BUILD_CUSTOM -DF_CPU=80000000L -D__ets__ -DICACHE_FLASH -DARDUINO=10805 -DARDUINO_BOARD="PLATFORMIO_ESP12E" -DFLASHMODE_DOUT -DLWIP_OPEN_SRC -DNONOSDK22x_190703=1 -DTCP_MSS=1460 -DLWIP_FEATURES=0 -DLWIP_IPV6=0 -Isrc -IlibAdafruit_SGP30-1.0.5 -IlibSparkFun_APDS-9960_Sensor_Arduino_Librarysrc -IlibAdafruit_MPR121 -IlibHT16K33 -Ilibesp8266-oled-ssd1306 -IlibLiquidCrystal_I2C -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266HTTPClientsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266HTTPUpdateServersrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesArduinoOTA -Ilibpubsubclientsrc -IlibI2Cdevlib -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266WebServersrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesServosrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesSDsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesSDFSsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266SdFatsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesLittleFSsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266mDNSsrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesDNSServersrc -IlibTinyGPSPlus-1.0.2src -IlibSDM_Energy_Meter -IlibRN2483-Arduino-Librarysrc -IlibRegexpsrc -IlibMechInputs -IlibNewPingESP8266 -IlibSerialDevices -IlibHLW8012_1.1.1src -IlibHeatpumpIR -IlibIRremoteESP8266src -IlibBlynksrc -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesESP8266WiFisrc -IlibArduinoJson-6.xsrc -IlibAM2320 -IlibAdafruit_NeoPixel -IlibAdafruit_Motor_Shield_V2 -IlibAdafruit_Motor_Shield_V2utility -Ilibccronexpr -IlibAS_BH1750 -IlibAdafruit_TSL2591 -IlibAdafruit_Sensor -IlibAdafruit_TCS34725 -IlibLOLIN_EPDsrc "-I.piolibdepscustom_ESP8266_4M1MAdafruit ILI9341" "-I.piolibdepscustom_ESP8266_4M1MAdafruit GFX Library" "-I.piolibdepscustom_ESP8266_4M1MAdafruit BusIO" -I.piolibdepscustom_ESP8266_4M1MESPeasySerial -IlibSC16IS752 -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesWire -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266librariesSPI -I.piobuildcustom_ESP8266_4M1Mcore -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdkinclude -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdklibcxtensa-lx106-elfinclude -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266coresesp8266 -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdklwip2include -IC:usersgijsn.platformiopackagesframework-arduinoespressif8266variantsnodemcu srcESPEasy.ino.cpp
xtensa-lx106-elf-g++ -o .piobuildcustom_ESP8266_4M1MESP_Easy_mega_20201012_custom_ESP8266_4M1M.elf -T eagle.flash.4m1m.ld -Os -nostdlib -Wl,--no-check-sections -Wl,-static -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read -u app_entry -u _printf_float -u _scanf_float -u _DebugExceptionVector -u _DoubleExceptionVector -u _KernelExceptionVector -u _NMIExceptionVector -u _UserExceptionVector @"C:GitHubTD-erESPEasy.piobuildcustom_ESP8266_4M1Mlongcmd-a302cf0692c4fc5d40ee988c2df28d2a" -L.piobuildcustom_ESP8266_4M1M -L.piobuildcustom_ESP8266_4M1Mld -LC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdklib -LC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdkld -LC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdklibcxtensa-lx106-elflib -LC:usersgijsn.platformiopackagesframework-arduinoespressif8266toolssdklibNONOSDK22x_190703 -Wl,--start-group .piobuildcustom_ESP8266_4M1MlibFrameworkArduinoVariant.a .piobuildcustom_ESP8266_4M1MlibFrameworkArduino.a -lstdc++ -lhal -lphy
-lpp -lnet80211 -lwpa -lcrypto -lmain -lwps -lbearssl -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc -llwip2-1460 -Wl,--end-group
xtensa-lx106-elf-g++: error: CreateProcess: No such file or directory
*** [.piobuildcustom_ESP8266_4M1MESP_Easy_mega_20201012_custom_ESP8266_4M1M.elf] Error 1
=========================================================================================================================================================================== [FAILED] Took 9.96 seconds ===========================================================================================================================================================================
This is less than 6k, so I am not entirely sure it will be the true error.
If you like, I can also make a full verbose build, but I guess the log will not entirely fit in the terminal window.
The linker also expands C:GitHubTD-erESPEasy.piobuildcustom_ESP8266_4M1Mlongcmd-a302cf0692c4fc5d40ee988c2df28d2a file when finally invokes CreateProcess. How many symbols are there?
Just made a new test build on this laptop to check.
Size of the file: 34.1 KB (34,986 bytes)
It contains all .cpp.o files incl path, so that does explain why some envs had this issue while others didn’t experience it.
For example:
".pio/build/custom_alt_wifi_ESP8266_4M1M/src/src/WebServer/WebServer_login.cpp.o"
Right now, quite a lot of function still have a global scope (left over from converting from .ino files)
Would it be helpful for this particular issue if I move some into their own class?
Then the separate files would first be linked into a new (bigger) .o file.
Disadvantage is that the linker may not be as effective in leaving out unused functions.
Does it make sense to move some common functionality to standalone libraries? PlatformIO will be able to link them as static archives so it should help with the long linker command.
I can try, to see if this file will be smaller.
But still, if functions are not used, they will not be left out of the final binary right?
If something is used from the «library», then the entire object will be linked.
Thanks to the -Wl,--gc-sections flag, unused functions won’t be linked.
Also if they are part of a library?
Doesn’t matter, the linker is smart enough to throw out unnecessary symbols even from libraries.
Good to know.
I will try to split some into the lib dir.
I now was looking again into this issue and thus also did look at the longcommand-<hexvalue> file.
It does have an entry per .cpp.o file, including all library code used.
Just a small section of this:
".pio/build/custom_ESP8266_4M1M/libf62/SPI/SPI.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib525/Wire/Wire.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib551/SC16IS752/SC16IS752.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib9e8/ESPeasySerial/ESPEasySC16IS752_Serial.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib9e8/ESPeasySerial/ESPEasySerial_ESP32.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib9e8/ESPeasySerial/ESPEasySerial_ESP8266_noSWserial.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib9e8/ESPeasySerial/ESPEasySoftwareSerial.cpp.o"
".pio/build/custom_ESP8266_4M1M/lib9e8/ESPeasySerial/ESPeasySerial_ESP8266.cpp.o"
(It is all in one line, but for readability, I placed each on a single line)
As you can see, the .cpp.o files here are from a library but still are used in this longcommand.
So I don’t think it will help here to move parts to their own library, or am I missing something here?
Just as an idea…
All lines use the same path prefix, which in my example uses 30 bytes per entry and this (failed) longcommand file has 426 entries.
So if the longcommand could be generated relative to the common path, it would save over 12 kByte in size.
Could this file be used with some relative path?
I just found a bit more room by going over the libraries mentioned in the lib_ignore part of an environment definition.
Still this does not appear to be a fix for all my environments, so I will continue to dig further.
Edit:
Setting lib_ldf_mode = deep+ does help here, but not in all environments. 
OK, dug a bit deeper into what is happening here and I found the deep+ does only scan for libraries to be included or ignored, not individual cpp/h files (which is also implied by the name of lib_ldf_mode)
This means I cannot continue to convert the rest of the .ino files in my project to .cpp/.h files or else I will run into build issues I cannot find a work-around for.
To explain this, you need to know the structure of my project.
- ESPEasy has a number of core elements (Rules processing / WiFi / event handling / webserver / etc)
- Interaction with sensor hardware is done via so called plugins.
- Sending out data is done via Controller plugins (e.g. to MQTT broker)
These plugins and controllers are now coded in .ino files, but some already use objects coded in .cpp/.h files
Those are only included when the specific .ino Plugin file is meant to be included in the build.
But the .cpp.o files of those all occur in the longcmd file.
Meaning if I convert the other Plugin .ino files to .h/.cpp files they will all end up in the longcmd file and thus every build will fail. (currently we have over 100 plugin and controller .ino files)
The only thing I can think of right now, will be a true nightmare to maintain as it means every plugin and every controller will end up in a separate library.
So I really hope there is a better solution for this.
Maybe @ivankravets may have a suggestion here to overcome this issue?
Edit:
There may be a really dirty work-around for it, if I don’t convert the plugin .ino files to .h files instead of .cpp files.
These .h files must then be included in a single .cpp file (only once) acting as a wrapper.
But I really dislike this idea due to the fact all code in such a .h file will be inline.
Meaning if a function is defined there and called twice, it will result in a larger executable file.
And still I need to have code in separate files which will be present in all compile runs.
It is something I really don’t like to do.
The only thing I can think of right now, will be a true nightmare to maintain as it means every plugin and every controller will end up in a separate library.
Could you please explain in a few words what exactly is hard to maintain it that case? In my opinion, isolated modules (the granularity of that modules may vary as your project evolves) should be much easier to develop and implicitly lead to better software design.
The main issue here is that all project files are located in the src folder, all these files are linked as objects in the final command. We need to move away from that structure by extracting related parts of the project into separate modules that can be linked as static archives.
Could you please explain in a few words what exactly is hard to maintain it that case? In my opinion, isolated modules (the granularity of that modules may vary as you project evolves) should be much easier to develop and implicitly lead to better software design.
Well it depends on what PlatformIO may find acceptable as a library.
If the «library per plugin» can simply be a directory in the libs folder without an existing git repository, then it only adds some overhead in library.json and library.properties file.
But it can still reside in the main repository of my project.
This way, if I change something that may affect a number of plugins, then it could still all be in a single commit.
If I also need to update dozens of separate repositories, then it will be a nightmare to maintain.
Right now I am still in the process of refining the interface between the core and the plugins, so the interface between the plugins and core is still a bit in flux.
Meaning some changes may affect quite some plugin files.
I wonder how building it in Arduino IDE will be affected by such changes.
How does Arduino IDE link all .cpp.o files? Do they also run into these Windows command line length limitations?
If the «library per plugin» can simply be a directory in the libs folder without an existing git repository, then it only adds some overhead in library.json and library.properties file.
But it can still reside in the main repository of my project.
You can group your libs as you like and keep them in your main repository, that’s what the lib folder was made for. You don’t even need the library.json file by default.
How does Arduino IDE link all .cpp.o files? Do they also run into these Windows command line length limitations?
Arduino IDE (as any other app) is exposed to that limitation since it’s imposed by the OS.
I do understand why it may fail, if it indeed tries to generate a similar line.
The main problem for me is that PlatformIO can be instructed to ignore a library, but not sure how Arduino IDE may handle this.
Does Arduino IDE try to create separate intermediate files first or does it also generate .o files from every .cpp file it finds and then trying to link it at once.
Does Arduino IDE try to create separate intermediate files first or does it also generate .o files from every .cpp file it finds and then trying to link it at once.
If I’m not mistaken, Arduino IDE links only framework files and libraries as static archives. Project source files are linked as objects.
OK, that would make sense.
Probably still need to check it before I make my final decision on how to proceed with this.
I was just thinking about this a bit more and I realized this (which I hope isn’t correct).
Imagine I will create a library of every single plugin and controller (e.g. just about any .ino file left in my project)
These plugins do need parts of the core of my project, but you just can’t include parts of the main project in the library.
This implies the entire core should also be moved into a library.
Thus my entire project would then consist of a single file including all libraries.
Isn’t that a bit defeating the whole idea of making if more structured?
And it is all needed to overcome a truly silly limitation, that we cannot freely create a build based on a number of pre-selected compiled object files.
I just got the feeling it is heading in a completely wrong direction.
Assuming I grasp the problem, perhaps Platformio’s linker could copy all the files to a temporary root folder, then link the files there. Afterwords, cleanup by deleting the temp folder.
It seems to me that would reduce the command line length in a typical build environment. And this alternate linking method could be an option enabled by an entry in platformio.ini, where the drive root folder could be specified.
- Thomas
Yep it seems it is indeed a PIO core issue.
And stripping the shared path of all .cpp.o file entries might save roughly 12k in my project’s longcmd file.
I will have a look at what was discussed in the topics you linked.
This was referenced
Oct 22, 2020
@TD-er i reorganized the libs in Tasmota in subfolders. Reason was not a compile fail.
The compile time was growing more and more because Platformio compiles all libs even when not used. Tasmota does not use libdeps (no easy change…) So i grouped the libs, and activate only
the groups needed for the variant build. No code change needed and the compile time is reduced nicely. Maybe a way for your issue?
@Jason2866
Yep, I was also thinking about something similar.
Another option could be to use the Python scripts I already use in my PIO envs to deduct the needed libraries and thus generate a lib_ignore for a specific build.
This means I have to transfer my build defines to the Python layer, which may not be a bad thing.
Right now I do have the problem that I sometimes need to define things at compile arguments and not in my C++ project code as they are needed for libraries.
So it is already a bit of a mix between where to put the defines, which makes it not always clear to users where to put the defines.
@TD-er Had the idea with dynamic disabling libs too. After working on it i trashed the idea.
The amount of (extra) stuff needs maintaining was more than i thought.
After looking which libs are used for the different Tasmota versions it was easy with libs folder groups. A nice automatic disabling libs (python) PIO thing would be still great.
If you have something please let me know
Yep as soon as I found the best fix for ESPEasy, I will let you know.
Still it would also be nice if we didn’t hit this limit and it is fixed in PlatformIO 
Hi all,
Could you show an example of platformio.ini and explain what you would like to achieve? Maybe I can give you some advice. Thanks!
Right now we do hit a limit in the longcmd file generated.
So if the path to all .cpp.o files could be shortened, then the problem «magically» disappears (for a while)
On the other hand, if we could somehow determine what library is used, it does not have to be compiled (thus saving time and an entry in the longcmd file)
So there either needs to be a practical way to populate the lib_ignore from a Python script during build, or a list of files (not folders) that can be excluded/included using the same Python script route.
Edit:
See my setup: https://github.com/letscontrolit/ESPEasy
For example this line: https://github.com/letscontrolit/ESPEasy/blob/d0faa2dd4d5a00deac6583e63665d09c8d681fcf/platformio_esp82xx_envs.ini#L24
If you remove the IRremoteESP8266, HeatpumpIR no ESP8266 «custom» build can be built again.
lib_deps instructs PlatformIO to download this dependency, install on your machine, and include in ba build process. Do you mean that you want only «INSTALL» stage? And later just use lib_ldf_mode = chain+.
In this case, you need to do the next:
- Do not use
lib_depsif you don’t need this library in a build process - Create PRE extra script and manage dependencies on a disk manually. See lines of code https://github.com/platformio/platformio-core/blob/develop/platformio/builder/tools/piolib.py#L885
lm = LibraryPackageManager( env.subst(os.path.join("$PROJECT_LIBDEPS_DIR", "$PIOENV")) ) for spec in custom_specs: if lm.get_package(spec): lm.install(spec)
custom_specs — could be an option from platformio.ini, for example, custom_lib_deps = .... Then use
env.GetProjectConfig().get(
"env:" + self.env["PIOENV"], "custom_lib_deps"
)
In Tasmota we do NOT use lib_deps all libs are local (adopt for Tasmota).
We use already lib_ldf_mode=chain+
So the way you described is the way that fits
Thx. It is on my todo list. Idk when i have time for. At the moment the way we do is good enough
If you use lib_ldf_mode=chain+ — how it is possible that PlatformIO builds libraries that you do not need?
Idk. Without the libs are missing. With it it compiles every lib found in folder if used in code or not
It is not in the resulting firmware. Linker does his job.
Even with deep+ the local libraries are still built.
And the files all appear in the longcmd file.
Only when ignoring the libs, the files are not built.
Just like Tasmota, the ESPEasy libs folder is filled with adapted versions of libraries.
And I am considering to «misuse» the libs idea to convert all plugins of ESPEasy into «libraries» so you can exclude them from the build (meaning the number of libraries will then be 100 libraries more, so probably hit another limit?)
I’m not sure what config the ldf scanner uses to determine whether a library is needed?
Does it process the #define checks?
Does it process the #define checks?
Yes, it follows macros but is not so smart. It does not have information about toolchain’s macros. We do not use native GCC preprocessor and use soft version written in Python (part of SCons). We have a feature request to use native GCC Preprocessor but this way will significantly increase compilation time.
That explains it. We hope the feature request will be done (soon)😍
Thanks for your awesome work and your great support.
Without PlatformIO Tasmota would not be possible!
Would it be possible to make a filter on files to include/exclude in a build?
For example, if I have a list of defines in Python like these:
if os.path.isfile('src/Custom.h'): env.Append(CPPDEFINES=["USE_CUSTOM_H"]) else: env.Append(CPPDEFINES=[ "CONTROLLER_SET_ALL", "NOTIFIER_SET_NONE", # "PLUGIN_BUILD_NORMAL", "USES_P001", # Switch "USES_P002", # ADC "USES_P004", # Dallas DS18b20 "USES_P100", # Pulse Counter - DS2423 "USES_C016", # Cache Controller "USES_C018", # TTN/RN2483 "FEATURE_MDNS", "FEATURE_SD", "FEATURE_I2CMULTIPLEXER", "USE_SETTINGS_ARCHIVE" ])
As you can see, there is quite a simple structure, which can also be found in the .cpp and .h files (at this moment still .ino files, but I can transform them into .h/.cpp files)
My other idea was to convert them into libraries, which can be added to either lib_deps or lib_ignore.
I can also create folders, but I’m not sure when I will hit another command line limit when basing a filter on source folders.
It’s possible to tune your build process following macros which are visible to SCons. You can see them in pio run -v or pio run -t envdump and check flags.
Thank you too for using PlatformIO!
If you put dependency includes under #ifdef USES_P002 (for example), the LDF should understand this and ignore these includes.
I think they are all used in such a structure.
Only problem right now is that the plugins still are in .ino files, which may cause the LDF to find them, even though the includes that refer to the libraries are all within the #ifdef USES_Pxxx checks.
Problem is, if I convert them to .cpp/.h too, I will very soon hit the limit of the longcmd again.
And about using PIO… I truly have no idea how to work without it anymore.
Some users still want to build using Arduino IDE, but I really don’t understand why…
I am again running into this nasty command line limit and am a bit out of options now to think of new work arounds for it.
The only thing I can now think of is creating a single large .cpp file of all separate .cpp files in a specific directory.
This is of course not a desired fix.
Another thing I can do is:
- move the .cpp files to another directory away from the .h files
- Exclude that dir from building
- let the pre-build Python script concatenate all .cpp files to a single .cpp file and move that one to a dir where it can be built (to keep include paths working)
This way I still have the files separate so a change on a single file is still usable in Git blame.
I tried to make some Python scripts to concatenate .cpp files in a specific directory and exclude the original dir.
See letscontrolit/ESPEasy#3409
Problem here is that the source filter not appears to be working to exclude the orginal .cpp files.
Import("env") import os import glob cpp_files = [] cpp_path = './src/src/PluginStructs' cpp_path_out = './src/src/PluginStructs_tmp' if not os.path.exists(cpp_path_out): os.makedirs(cpp_path_out) tmp_cpp_file = os.path.join(cpp_path_out, '__tmpfile.cpp') if os.path.exists(tmp_cpp_file): os.remove(tmp_cpp_file) for root, dirs, files in os.walk(cpp_path): for file in files: if file.endswith('.cpp'): fullname = os.path.join(root, file) cpp_files.append(fullname) print("Add {}".format(fullname)) with open(tmp_cpp_file,'wb') as newf: for filename in cpp_files: with open(filename,'rb') as hf: newf.write(hf.read())
I tried several filters for the src_filter, but it doesn’t appear to be working.
Specifically excluding the files that are concatenated:
src_filter = +<*> -<.git/> -<.svn/> -<example/> -<examples/> -<test/> -<tests/> -<P*_data_struct.cpp>
Or excluding the original path:
src_filter = +<*> -<.git/> -<.svn/> -<example/> -<examples/> -<test/> -<tests/> -<src/src/PluginStructs/>
The output of the linker still suggests the old .cpp files are being compiled:
c:/users/gijsn/.platformio/packages/toolchain-xtensa@2.40802.200502/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio/build/custom_ESP8266_4M1M/src/src/PluginStructs_tmp/__tmpfile.cpp.o: in function `P045_data_struct::loop()':
__tmpfile.cpp:(.text._ZN16P045_data_struct4loopEv+0x1c): multiple definition of `P045_data_struct::loop()'; .pio/build/custom_ESP8266_4M1M/src/src/PluginStructs/P045_data_struct.cpp.o:P045_data_struct.cpp:(.text._ZN16P045_data_struct4loopEv+0x1c): first defined here
@ivankravets
I hope you can push me in the right direction here, to create a work-around for this issue.
Ah…. this one appears to be working:
src_filter = +<*> -<.git/> -<.svn/> -<example/> -<examples/> -<test/> -<tests/> -<*/PluginStructs/>
I’m hitting these issues again and now I’m running out of my own files to concatenate in the Python script mentioned above.
Right now I also tried to concatenate some library which does have quite a lot of .cpp files in it which makes it possible to compile on Windows again but since that library was never intended to have all .cpp files concatenated into a single large file I am running into other issues like 0 maintainability on upgrades of that library and linker issues on Linux.
I also found this PR, which should fix this issue as far as I could understand, but apparently it doesn’t for me. (issue it tried to fix: platformio/platformio-core#3792 )
But maybe it isn’t the exact same problem as my linker error is:
xtensa-esp32-elf-g++: error: CreateProcess: No such file or directory
I really would like to see a proper fix as my patch to concatenate files in the build process does have some side-effects like Intellisense often pointing me to the wrong file and I only find out I was editing the wrong file after all my edits were lost when building. (happened a lot, really frustrating)
So please, can we somehow make a proper fix for this?
Or is there already one magic project setting which I simply overlooked?
That would be great if it is fixed in the tool chain.
Right now it is mainly a problem for me with ESP32 builds, but it is just a matter of time before it will happen again on ESP8266.
Apparently there is something merged which should (hopefully) fix this….
See: espressif/esp-idf@d836163
Can this also be used for ESP8266 toolchain, or do we use a different version for both platforms?
I had a very long path, and there’s a file in there somewhere (not gcc.exe) but another file, that gcc.exe is accessing from the path..
So when I cleared the path, it worked
C:MinGW>cd bin
C:MinGWbin>where gcc.exe
C:MinGWbingcc.exe
C:Perl64sitebingcc.exe
^^ So running gcc from there will definitely run the ming gcc.exe
C:MinGWbin>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);
}
Compiling it I got this error
C:MinGWbin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
My PATH was huge
C:MinGWbin>path
PATH=C:Windowssystem32;C:Windows;C:Windowssystem32wbem;C:P......
C:MinGWbin>path | grep -io «ming»
It didn’t have ming there.
C:MinGWbin>echo MING | grep -io «ming»
MING
(and yeah that grep works..the path didn’t have ming there)
Clearing my path completely, led it to work!
C:MinGWbin>set PATH=
C:MinGWbin>gcc file6.c
C:MinGWbin>
So, it’s not clear yet precisely what it was in the PATH that led to the clash. What directory, what file.
Update-
The above seems to be correct to me but to add, it’s also not a simple case of something earlier in the path clashing.. because normally the current directory takes precedence. And it does here in so far as gcc —version shows it’s running the ming one and not one of the ones in a conflicting directory. So there’s something funny going on that, if the conflicting directory is in the path) , one has to either do .gcc or add . to the start of the path or add c:MinGWbin before any conflicting directories in the path. this is the case even when you’re in C:MinGWbin and that’s strange. And when it gives an error, it is still running Ming’s gcc but (For some reason) looking at the conflicting directory too, as I see from process monitor. There may be more of an answer here http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista in the link mentioned in the very upvoted answer here
That’s Ming32 bit..
Looking at Ming 64bit, probably has te same issue, but I see, interestingly, it comes with a bat file that (sensibly) actually puts the bin directory at the tart of the path. And it looks like that is a standard way of running Ming gcc properly.
The code::blocks IDE (sensibly) also puts the bin directory at the start of the path. If you run a C program that shows environment variables then you see that.
Bug 89249
— mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory
Summary:
mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No…
|
I know that supporting Windows was always a big pain, so I can fully understand people not being over joyed when seeing such errors... I also noticed that reports related to CreateProcess are usually refered to mingw; or that local configurations are blamed, like wrong paths. However, in my case, the specifics may point to a possible bug in gcc, althougt I do not exclude an interraction with the mingw runtime. The problem occured in a configuration which used spaces in the install path, and went away when I moved **exactly** the same toolchain to a folder without spaces in the names. Another detail is that the problem occured only when using -flto, and did not occur when exactly the same project was compiled without -flto. The linker output with the error: --- Building target: f4b-lto.elf Invoking: GNU ARM Cross C++ Linker arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -fno-move-loop-invariants -Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4b-lto.map" --specs=nano.specs -v -o "f4b-lto.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o Using built-in specs. Reading specs from c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCCx2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit) COMPILER_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-ffreestanding' '-flto' '-fno-move-loop-invariants' '-Wall' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'f4b-lto.elf' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe -flto --sysroot=c:usersilgdesktop8.2.1 1.4-20190207-1853bin../arm-none-eabi -X -o f4b-lto.elf -L../ldscripts -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1 -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib --gc-sections -Map f4b-lto.map ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o -lstdc++_nano -lm --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc -lc_nano --end-group -T mem.ld -T libs.ld -T sections.ld collect2.exe: fatal error: CreateProcess: No such file or directory compilation terminated. make: *** [makefile:64: f4b-lto.elf] Error 1 "make all" terminated with exit code 2. Build might be incomplete. --- The offending name is 'c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin'. After replacing the spaces with a dash, the link step was ok: --- Building target: f4b-lto.elf Invoking: GNU ARM Cross C++ Linker arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -fno-move-loop-invariants -Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4b-lto.map" --specs=nano.specs -v -o "f4b-lto.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o Using built-in specs. Reading specs from c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCCx2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit) COMPILER_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-ffreestanding' '-flto' '-fno-move-loop-invariants' '-Wall' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'f4b-lto.elf' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe -flto --sysroot=c:usersilgdesktop8.2.1-1.4-20190207-1853bin../arm-none-eabi -X -o f4b-lto.elf -L../ldscripts -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1 -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib -Lc:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib --gc-sections -Map f4b-lto.map ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o -lstdc++_nano -lm --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc -lc_nano --end-group -T mem.ld -T libs.ld -T sections.ld c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o arm-none-eabi-g++ @C:UsersilgAppDataLocalTempccEwHABd Using built-in specs. Reading specs from c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCCx2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit) COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-mcpu=cortex-m4' '-mfloat-abi=soft' '-Og' '-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-fno-move-loop-invariants' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-dumpdir' './' '-dumpbase' 'f4b-lto.elf.wpa' '-fltrans-output-list=C:UsersilgAppDataLocalTempcc7QvyUG.ltrans.out' '-fwpa' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/arm-none-eabi/8.2.1/lto1.exe -quiet -dumpdir ./ -dumpbase f4b-lto.elf.wpa -mcpu=cortex-m4 -mfloat-abi=soft -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -march=armv7e-m -auxbase stm32f4xx_hal -g3 -Og -Og -Wextra -version -fno-openmp -fno-openacc -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-move-loop-invariants -fltrans-output-list=C:UsersilgAppDataLocalTempcc7QvyUG.ltrans.out -fwpa @C:UsersilgAppDataLocalTempccNMzFgH GNU GIMPLE (GNU MCU Eclipse ARM Embedded GCC, 64-bit) version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (arm-none-eabi) compiled by GNU C version 7.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GNU MCU Eclipse ARM Embedded GCC, 64-bit) version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (arm-none-eabi) compiled by GNU C version 7.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COMPILER_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-mcpu=cortex-m4' '-mfloat-abi=soft' '-Og' '-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-fno-move-loop-invariants' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-dumpdir' './' '-dumpbase' 'f4b-lto.elf.wpa' '-fltrans-output-list=C:UsersilgAppDataLocalTempcc7QvyUG.ltrans.out' '-fwpa' '-march=armv7e-m' arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -march=armv7e-m -r -nostdlib -o C:UsersilgAppDataLocalTempccXSGpBYdebugobj C:UsersilgAppDataLocalTempcckhSqwJdebugobjtem C:UsersilgAppDataLocalTempcc5FxM2wdebugobjtem C:UsersilgAppDataLocalTempcckuo93mdebugobjtem C:UsersilgAppDataLocalTempcch75PPgdebugobjtem C:UsersilgAppDataLocalTempcc8C50hddebugobjtem C:UsersilgAppDataLocalTempcc5vvwYbdebugobjtem C:UsersilgAppDataLocalTempccezFo7cdebugobjtem C:UsersilgAppDataLocalTempccRJrCCfdebugobjtem C:UsersilgAppDataLocalTempccsn1FFkdebugobjtem C:UsersilgAppDataLocalTempcctYKysodebugobjtem C:UsersilgAppDataLocalTempcc4jVjSvdebugobjtem C:UsersilgAppDataLocalTempccDSQRqCdebugobjtem C:UsersilgAppDataLocalTempcc6t99rMdebugobjtem C:UsersilgAppDataLocalTempccR8QIyWdebugobjtem C:UsersilgAppDataLocalTempccXRnUxYdebugobjtem C:UsersilgAppDataLocalTempccvnwwnZdebugobjtem C:UsersilgAppDataLocalTempccbzifT2debugobjtem C:UsersilgAppDataLocalTempcchyjUR7debugobjtem C:UsersilgAppDataLocalTempccnV6hGgdebugobjtem C:UsersilgAppDataLocalTempccJMPhksdebugobjtem C:UsersilgAppDataLocalTempccDx0FuFdebugobjtem C:UsersilgAppDataLocalTempccNESo4Sdebugobjtem C:UsersilgAppDataLocalTempccL1ttg9debugobjtem C:UsersilgAppDataLocalTempcczjpscrdebugobjtem C:UsersilgAppDataLocalTempccTJERdIdebugobjtem C:UsersilgAppDataLocalTempccxESMi3debugobjtem C:UsersilgAppDataLocalTempcc7CjJFqdebugobjtem arm-none-eabi-g++ @C:UsersilgAppDataLocalTempccTzgy7o Using built-in specs. Reading specs from c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCCx2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit) COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-mcpu=cortex-m4' '-mfloat-abi=soft' '-Og' '-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-fno-move-loop-invariants' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-dumpdir' './' '-dumpbase' 'f4b-lto.elf.ltrans0' '-fltrans' '-o' 'C:UsersilgAppDataLocalTempcc7QvyUG.ltrans0.ltrans.o' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/arm-none-eabi/8.2.1/lto1.exe -quiet -dumpdir ./ -dumpbase f4b-lto.elf.ltrans0 -mcpu=cortex-m4 -mfloat-abi=soft -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -march=armv7e-m -auxbase-strip C:UsersilgAppDataLocalTempcc7QvyUG.ltrans0.ltrans.o -g3 -Og -Og -Wextra -version -fno-openmp -fno-openacc -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-move-loop-invariants -fltrans @C:UsersilgAppDataLocalTempcc6fdxVa -o C:UsersilgAppDataLocalTempccqmesT9.s GNU GIMPLE (GNU MCU Eclipse ARM Embedded GCC, 64-bit) version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (arm-none-eabi) compiled by GNU C version 7.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GNU MCU Eclipse ARM Embedded GCC, 64-bit) version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (arm-none-eabi) compiled by GNU C version 7.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-mcpu=cortex-m4' '-mfloat-abi=soft' '-Og' '-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-fno-move-loop-invariants' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-dumpdir' './' '-dumpbase' 'f4b-lto.elf.ltrans0' '-fltrans' '-o' 'C:UsersilgAppDataLocalTempcc7QvyUG.ltrans0.ltrans.o' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/as.exe -v -march=armv7e-m -mfloat-abi=soft -mfloat-abi=soft -meabi=5 -o C:UsersilgAppDataLocalTempcc7QvyUG.ltrans0.ltrans.o C:UsersilgAppDataLocalTempccqmesT9.s GNU assembler version 2.31.51 (arm-none-eabi) using BFD version (GNU MCU Eclipse ARM Embedded GCC, 64-bit) 2.31.51.20181213 COMPILER_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/lib/gcc/../../libexec/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/;c:/users/ilg/desktop/8.2.1-1.4-20190207-1853/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-mcpu=cortex-m4' '-mfloat-abi=soft' '-Og' '-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-fno-move-loop-invariants' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-dumpdir' './' '-dumpbase' 'f4b-lto.elf.ltrans0' '-fltrans' '-o' 'C:UsersilgAppDataLocalTempcc7QvyUG.ltrans0.ltrans.o' '-march=armv7e-m' COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-ffreestanding' '-flto' '-fno-move-loop-invariants' '-Wall' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'f4b-lto.elf' '-march=armv7e-m' Finished building target: f4b-lto.elf --- In the initial folder using spaces, a project not using -flto link passed: --- Building target: f4b.elf Invoking: GNU ARM Cross C++ Linker arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4b.map" --specs=nano.specs -v -o "f4b.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o Using built-in specs. Reading specs from c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCCx2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit) COMPILER_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-ffreestanding' '-fno-move-loop-invariants' '-Wall' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'f4b.elf' '-march=armv7e-m' c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe --sysroot=c:usersilgdesktop8.2.1 1.4-20190207-1853bin../arm-none-eabi -X -o f4b.elf -L../ldscripts -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib/thumb/v7e-m/nofp -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1 -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib -Lc:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../arm-none-eabi/lib --gc-sections -Map f4b.map ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o -lstdc++_nano -lm --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc -lc_nano --end-group -T mem.ld -T libs.ld -T sections.ld COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-mfloat-abi=soft' '-Og' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-ffreestanding' '-fno-move-loop-invariants' '-Wall' '-Wextra' '-g3' '-T' 'mem.ld' '-T' 'libs.ld' '-T' 'sections.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'f4b.elf' '-march=armv7e-m' Finished building target: f4b.elf --- I might be wrong, but, if I read the message 'collect2.exe: fatal error: CreateProcess...' correctly, it looks like collect2 is not able to start a subprocess, probably lto-wrapper.exe or lto1.exe. A possible reason for this is that collect2 gets confused by the space in the path. lto*.exe are not in the system path, only '<top>/bin' is, where gcc/g++ are located. From here gcc/g++ probably compute a relative path to '<top>/libexec/gcc/arm-none-eabi/8.2.1', where they find collect2. collect2 must do the same to locate lto*.exe. I'm not very familiar with the source code, so I don't know exactly where to search for, but one starting point would be to investigate why gcc/g++ properly identify collect2, and collect2 fails to identify lto*. Normally they shuld all share the code to compute the relative path, but maybe they do not, or do not call it the same. If someone with more deep knowledge on how things work can suggest a place to add extra debug messages, I can build new binaries to further investigate.
I see COLLECT_LTO_WRAPPER with properly escaped spaces but COMPILER_PATH not. This is build from gcc.c:build_search_list which is simplistic so 'paths' and 'prefix' have to be escaped properly already. The paths are populated from find_a_file.
Hi Richard,
Thank you for taking the time to investigate.
Indeed, COLLECT_LTO_WRAPPER is escaped, while COMPILER_PATH is not:
COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe
...
COMPILER_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/
However, COMPILER_PATH is also not escaped in the no-LTO case, which works, so I guess it is escaped somewhere else, and this is missing in the LTO code.
The only meaningful place where COMPILER_PATH is used is in gcc.c:driver::maybe_run_linker():
putenv_from_prefixes (&exec_prefixes, "COMPILER_PATH", false);
putenv_from_prefixes (&startfile_prefixes, LIBRARY_PATH_ENV, true);
Right now I see convert_white_space() called only twice:
lto_wrapper_file = find_a_file (&exec_prefixes, "lto-wrapper",
X_OK, false);
and
linker_plugin_file_spec = convert_white_space (temp_spec);
From what I undestand, the path in 'exec_prefixes' should have been converted before putenv_from_prefixes() is called.
'exec_prefixes' seems constructed via
add_prefix (&exec_prefixes, arg, NULL,
PREFIX_PRIORITY_B_OPT, 0, 0);
From here... I'm kind of lost, the logic to manage paths is complex and I can't estimate the impacts of changes, but I think that this path change mandatory for Windows should be done in a single place, not everywhere the paths are finally consumed.
So, we got a bit of understanding, but the ploblem seems to require more thinking and a careful solution, which I'm not able to provide.
However, if someone can, I'm ready to try it.
I added a printf() in pex_win32_exec_child() to see why the lto invocation fails, and here is the result:
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe') <<<<<
>>>>> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe') <<<<<
collect2.exe: fatal error: CreateProcess: No such file or directory
compilation terminated.
C:Usersilgtmplto>
it looks like the win32 api is not happy with the escaped spaces in the lto-wrapper path.
I conditionally removed the white space conversion in gcc.c (around line 7741) and the problem was fixed:
#if defined (__MINGW32__)
// Win32 fails to CreateProcess if spaces are escaped.
lto_wrapper_spec = lto_wrapper_file;
#else
lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif
I did the same for the second reference to convert_white_space(), while processing the linker_plugin_file_spec, but I do not have a clear reason why this is needed, since aparently the name of the temporary files used for the specs file is generate by win32 in the 8.3 format, and has no spaces.
I tried to remove the conversion entirely, but then ld fails to load the plugin:
/home/ilg/Desktop/8.2.1 1.4-20190213-1020/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: /home/ilg/Desktop/8.2.1: error loading plugin: /home/ilg/Desktop/8.2.1: cannot open shared object file: No such file or directory
collect2: error: ld returned 1 exit status
ilg@ilg-ud18lts64-gme:~/tmp/lto$
I'll apply a patch to build my distribution, but I think a more elaborate solution is needed.
Although not related to this issue, another curious thing was the sequence of 6 calls to nm shown by the trace. Are they expected?
The patch is wrong, it should read:
#if defined (__MINGW32__)
// Win32 fails to CreateProcess if spaces are escaped.
#else
lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif
I upgraded my mingw to 5.0.4 and I can no longer reproduce the problem, so I suggest we close this ticket for now and reopen if necessary.
*** Bug 98175 has been marked as a duplicate of this bug. *** |
Moderator: Moderators
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
MinGW collect2: CreateProcess: No such file or directory
Code: Select all
Using built-in specs.
COLLECT_GCC=C:MinGW32bing++.exe
COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)
COMPILER_PATH=c:/mingw32/bin/../libexec/gcc/mingw32/4.5.0/;c:/mingw32/bin/../libexec/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/;c:/mingw32/bin/../lib/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../../
COLLECT_GCC_OPTIONS='-mwindows' '-march=i686' '-msse' '-mfpmath=sse' '-mthreads' '-fsingle-precision-constant' '-frounding-math' '-mieee-fp' '-pipe' '-fno-strict-aliasing' '-O2' '-DNDEBUG' '-g' '-o' '......spring.exe' '-v' '-shared-libgcc'
c:/mingw32/bin/../libexec/gcc/mingw32/4.5.0/collect2.exe --subsystem windows -Bdynamic -u ___register_frame_info -u ___deregister_frame_info -o ......spring.exe c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../../crt2.o c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/crtbegin.o -Lc:/mingw32/bin/../lib/gcc/mingw32/4.5.0 -Lc:/mingw32/bin/../lib/gcc -Lc:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib -Lc:/mingw32/bin/../lib/gcc/mingw32/4.5.0/../../.. --verbose --enable-auto-import @CMakeFilesengine-default.dirobjects1.rsp --out-implib libspring.dll.a --major-image-version 0 --minor-image-version 0 -lmingw32 D:SourcemingwlibsliblibSDLmain.a D:SourcemingwlibsdllSDL.dll -lpthread -lopengl32 -lglu32 D:Sourcemingwlibsdllglew32.dll D:Sourcemingwlibsdllfreetype6.dll ....SystemSoundlibsound.a D:Sourcemingwlibsliblibdevil.a D:Sourcemingwlibsliblibboost_regex-mt.a D:Sourcemingwlibsliblibboost_thread-mt.a D:Sourcemingwlibsliblibboost_program_options-mt.a D:Sourcemingwlibsliblibboost_system-mt.a D:Sourcemingwlibsliblibboost_signals-mt.a ....liblualiblua.a ....lib7zlib7zip.a ....liboscpackliboscpack.a ....libminiziplibminizip.a ....libstrefloplibstreflop.a ....liblobbyliblobby.a -limagehlp -lws2_32 -lwinmm -lmingw32 D:SourcemingwlibsdllOpenAL32.dll D:Sourcemingwlibsdllogg.dll D:Sourcemingwlibsdllvorbisfile.dll D:Sourcemingwlibsdllvorbis.dll -lmingw32 D:SourcemingwlibsliblibSDLmain.a D:SourcemingwlibsdllSDL.dll -lpthread D:Sourcemingwlibsdllzlib1.dll D:Sourcemingwlibsliblibboost_thread-mt.a D:Sourcemingwlibsliblibboost_system-mt.a ....libstrefloplibstreflop.a -limagehlp -lws2_32 -lwinmm ....libmd5libmd5.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lgdi32 -lcomdlg32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw32/bin/../lib/gcc/mingw32/4.5.0/crtend.o
collect2: CreateProcess: No such file or directory
Has anyone else seen this one?
I’m assuming that collect2 is trying to run another program (perhaps ld.exe) but I can’t figure out the specifics. Is there a way to track execution requests or get more verbose output?
I’ve had the problem occur under several different installations of MinGW. I suspect it’s because I’m not installing under C:MinGW but while the official MinGW says to install there the TDM install specifically says NOT to and offers C:MinGW32 as the default. They wouldn’t offer a default if it didn’t work so what gives?
I’m using TDM installer stable 4.5.0 and as far as I can tell everything is where it is supposed to be.
PATH variable: C:MinGW32bin;C:MinGW32libexecgccmingw324.5.0
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 22 Sep 2010, 17:47
Ah. Running collect2 with -debug has revealed the problem. It’s unwrapping the @response file and passing the entire file list to ld.exe.
That completely defeats the purpose of using a response file in the first place (to get around the 32k limit on args).
I wonder if anybody in the Spring community has successfully built Spring on Win32/MinGW lately? I mean using the latest git source (as of last week), GCC 4.5.0+ and git mingwlibs. As far as I can tell linking spring.exe will exceed 32k characters and cause this error yet I seem to be the only person who is affected.
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 22 Sep 2010, 20:39
Yes, but this time your advice was bogus. The paths in question are relative paths generated by CMake. They look like this:
CMakeFilesengine-default.dir____GameGame.cpp.obj
CMakeFilesengine-default.dir____GameGameData.cpp.obj
…. etc ….
So it really doesn’t matter where the build directory is located because what counts is the paths inside the Spring source tree.
There’s a couple of paths to library files in the commandline but shortening them won’t save enough characters. As it is right now the complete arguments weight in at 33491 characters and the most I can save by reducing the build root is less than 100 characters.
-
jK
- Spring Developer
- Posts: 2299
- Joined: 28 Jun 2007, 07:30
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by jK » 22 Sep 2010, 21:13
SpliFF wrote:Yes, but this time your advice was bogus. The paths in question are relative paths generated by CMake. They look like this:
…
Doesn’t sound like you tested it …
Why open a thread when you don’t even test the advices?
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 22 Sep 2010, 22:36
jK, I guarentee it won’t make the slightest bit of difference.
If you want to try and prove me wrong be my guest. I may not be the worlds’ greatest expert on building complex projects like Spring but I’ve spent a LOT of time on this particular bug and I know exactly what is happening. I knew the first time hoijoi mentioned it that it wasn’t going to work.
I’ve already reported this to the mingw and TDM bug trackers as it’s almost certainly an issue with the MinGW binary releases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
https://sourceforge.net/tracker/?func=d … tid=974439
Even if shortening paths did help (it doesn’t) it would still just be delaying the inevitable. Sooner or later we’d be using C: as our build directories because as Spring grows so do the number of objects (at least until somebody refactors the whole project).
But as I said the paths causing the issue are all relative to the spring build directory, not the drive root. The few absolute paths being passed amount to a total of no more than about 200 characters in total while the amount of characters over 32k is something like 1400.
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 23 Sep 2010, 07:18
There is another option, though I’m not looking forward to it.
With help from the GCC bug report I believe I’ve tracked the problem down to an issue in the configuration of the TDM and official builds. The linker supports response files and collect supports passing them but it only does so if the toolchain was configured using —with-gnu-ld or it autodetects this from the ld on the build system. In other words the feature is there but it must be explicitly enabled when GCC is built.
The solution then is to rebuild gcc with this option set. This will create a collect2.exe that passes its args in a new response file to ld.exe.
I can’t imagine building a working MinGW GCC is going to be easy but I do have a working linux hosted mingw32 cross-compiler so it isn’t out of the realm of possibility either.
I could just resume building spring cross-compiled. My original motive for building on windows was to have a working GDB.exe but I’ve since learned about gdbserver which solves this issue for cross builds.
On the other hand that basically means until spring is split up, or the upstream packages adopt the fix, or a workaround is found, spring can no longer be built on windows (unless the VS builds work, which I doubt). So I’m going to try my hand at building a 4.5.0/dwarf2 based mingw32 GCC and put it up on my mirror if successful. No promises though.
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 23 Sep 2010, 19:57
I’ve tried «make spring» in the past. It doesn’t solve the problem.
The arguments in question are all objects (*.obj) being linked into spring.exe (though I believe spring-multithreaded is also affected).
To help people understand the issue better, I’ve attached the response file used by engine targets (which should be both spring and spring-multiheaded)
- Attachments
-
- objects1.rsp.txt
- D:SpringTestdebugrtsbuildsdefaultCMakeFilesengine-default.dirobjects1.rsp
- (30.88 KiB) Downloaded 26 times
-
SpliFF
- Posts: 1224
- Joined: 28 Jul 2008, 06:51
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by SpliFF » 06 Oct 2010, 02:52
I couldn’t get MinGW to build after trying for a few hours so I gave up and went back to cross-compiling on linux. I’ll just wait until there’s an upstream fix. I don’t even need this anymore because I learned how to use gdbserver and my linux box compiles ~12 times faster than my Windows box.
There are long-term plans to make spring more modular, which will reduce the number of C++ files built at once (you build libraries then link those). I wouldn’t hold my breath for it though.
Seems like the best shortterm solution is to do what jK did and try to get a working collect2.exe from somewhere else. I’m surprised though that the 3.4.5 versions works with a newer GCC.
jK, can you upload your working collect2? I’m going to make one last attempt to build GCC using a cross-compiler but if that fails I’m not going to waste any more time on this and that will have to be our official workaround (or VS 2005 for those that use it).
-
jK
- Spring Developer
- Posts: 2299
- Joined: 28 Jun 2007, 07:30
Re: MinGW collect2: CreateProcess: No such file or directory
Post
by jK » 06 Oct 2010, 03:00
I first tried a 4.4.0 one, but it failed too. So I tried the 3.4.5, which works and wonders me too, because the file is just 10% in size of the 4.5.0 one.
here the 3.4.5 one:
note: I needed to zip it because else the forum wouldn’t allow me to upload it
-
FLOZi
- MC: Legacy & Spring 1944 Developer
- Posts: 6240
- Joined: 29 Apr 2005, 01:14
-
hoijui
- Former Engine Dev
- Posts: 4344
- Joined: 22 Sep 2007, 09:51
Когда я компилирую файлы c++ и c вместе со следующей командой:
g++ io.c *.cpp -o main -D__STDC_FORMAT_MACROS
Возникает ошибка:
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
И на самом деле collect2.exe существует в правильном каталоге. Я перепробовал все решения, представленные в Интернете, но ни одно из них не сработало (и т. д. установить/очистить значения среды, попробовать другие версии mingw32…) Единственная причина, по которой я мог придумать, заключается в том, что g++.exe использует / в каталогах, а Windows вместо этого использует . Так есть ли другие решения для ошибки?
2 ответа
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.
Как я это решил.
А. добавьте -v в команду компиляции:
c:Programsgcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihfbinarm-none-linux-gnueabihf-gcc test5.c -o newbuiltFile.out -v
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:UserspopsAppDataLocalTempccTNEjZv.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:programsgcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihfbin../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:UserspopsAppDataLocalTempccjF1go9.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.
Б. Я проверил все перечисленные файлы — проверил путь и увидел их существование. ВНИМАНИЕ: изначально я особо не смотрел на размер файла (обычно я его не отображаю)
В. обратите внимание, что файлы *.DLL также вызывают другие функции/библиотеки. Так что, возможно, вы не все видите. это может быть действительно большой задачей для проверки всех файлов.
Д. Наконец-то я заметил, что мои основные файлы bin не установлены должным образом. см. изображение.
явно не удачная установка
> proper install should have files with size > 0 Kbytes.
улучшенная установка для моих основных исполняемых файлов корзины
Е. решение состояло в том, чтобы переустановить инструменты MinGW. Простая компиляция теперь работает правильно.
1
MikeF_Ballard
14 Ноя 2020 в 04:01
Что ж, наконец-то я успешно скомпилировал исходные файлы с помощью Visual Studio. Это не ответ на этот вопрос, но это выход, если другие решения не найдены.
0
shijy
28 Апр 2020 в 09:09
Я получаю эту ошибку всякий раз, когда я пытаюсь запустить GCC вне его каталога установки (E:MinGWbin).
Итак, допустим я в E:code и иметь файл с именем one.c. Бегущий:
gcc one.c -o one.exe даст мне эту ошибку:
gcc: CreateProcess: No such file or directory
единственным обходным путем является переход в каталог установки, запуск gcc оттуда и указание всех других путей. Моя переменная окружающей среды Path содержит E:MinGWbin.
любые предложения по устранению этой проблемы? Я запуск Windows XP SP3.
24 ответов
его специально сказали, что вам нужно перезагрузиться после установки переменных среды в windows для migwin.
У меня была аналогичная проблема, вызванная не установкой компилятора C++. В моем случае я собирал .cpp-файлы для расширения Python, но компилятор сначала вызывается как c:mingwbingcc — … исполняемый.
внутренне, gcc.exe заметит, что его попросили скомпилировать .файл cpp. Он попытается вызвать g++.exe и сбой с тем же сообщением об ошибке:
gcc.exe: CreateProcess: нет такого файла или каталога
по данным код:: блоки wiki, вам необходимо добавить C:MinGWlibexecgccmingw32MinGW-Version на PATH. Нет необходимости перезапускать, но вам нужно открыть другой терминал, чтобы получить новейший PATH настройки.
для MinGW-w64 это <mingw install directory>libexecgccx86_64-w64-mingw32.7.0
27
автор: Herberth Amaral
У меня просто была эта проблема.
в моем случае проблема была связана с проблемами при загрузке пакетов для GCC. Программа mingw-get думала, что закончила загрузку, но это не так.
Я хотел обновить GCC, поэтому я использовал mingw-get, чтобы получить более новую версию. По какой-то причине mingw-get думал, что загрузка для определенного файла закончена, но это не так. Когда он пошел, чтобы извлечь файл, я думаю, он выдал ошибку (которую я даже не потрудился посмотреть-я просто запустите «mingw-get update && mingw-get install mingw32-gcc» и оставьте его там).
чтобы решить, я удалил gcc, выполнив «mingw-get remove mingw32-gcc» , а также удалил файл пакета (тот, который mingw-get не полностью загрузил), который был в папке кэша mingw («C:MinGWvarcachemingw-getpackages» в моей системе), затем снова запустил команду install. Он загрузил и установил недостающие части GCC (он не полностью загрузил пакет GCC-core).
Что решена моя проблема.
интересно, что mingw-get был достаточно умен, чтобы продолжить загрузку GCC-core даже после того, как я удалил файл пакета в папке кэша, а также удалил пакет mingw32-gcc.
Я думаю, что более фундаментальной проблемой было то, что, поскольку файлы GCC-core не были установлены, cc1 не было. И gcc использует cc1. Я предполагаю, что, когда gcc попытался запустить cc1, он использовал CreateProcess где-то, проходя путь cc1, который не был путем существующий файл. Таким образом, сообщение об ошибке.
8
автор: Pedro Henrique A. Oliveira
у меня была точно такая же проблема.
после перепроверки моего PATH, Я понял, что установил оба Mingw (64 bit) и Cygwin (32 бит).
Проблема в том, что оба Mingw и Cygwin есть g++.
отключив пути Cygwin, ошибка исчезла.
Итак, это глупое сообщение об ошибке, потому что оно не говорит вам что файл, который он не может найти.
выполните команду еще раз с подробным флагом gcc -v чтобы увидеть, что gcc до.
в моем случае случилось так, что он пытался позвонить cc1plus. Я проверил, у меня его нет. Установил компилятор mingw на C++, а затем сделал.
получал то же сообщение об ошибке при попытке запуска из Cygwin со ссылками на установку mingw.
используя ту же установку mingw32-make-3.80.0-3.exe от http://www.mingw.org/wiki/FAQ и опция оболочки mingw из Start — > Programs — > на WinXP SP3 и gcc работает нормально.
эта проблема заключается в том, что вы используете материал суффикса верхнего регистра.C вместо строчных букв.c при компиляции с помощью Mingw GCC. Например, когда вам это нравится:
gcc -o stuff stuff.C
затем вы получите сообщение: gcc: CreateProcess: No such file or directory
но если вы это сделаете:
gcc -o stuff stuff.c
затем он работает. Я просто не знаю, почему.
У меня была такая же проблема, и ни одно из предложенных исправлений не работало для меня. Поэтому, хотя это старый поток, я думаю, что я мог бы также опубликовать свое решение, если кто-то еще найдет этот поток через Google(как и я).
для меня мне пришлось удалить MinGW / удалить папку MinGW и переустановить. После повторной установки он работает как шарм.
Я испытал аналогичную проблему. Первоначально добавление папки bin GCC в мой системный путь не решило проблему. Я нашел два решения.
первым было запустить пакетный файл, который я нашел в корне установки MinGW, mingwbuilds.летучая мышь. Он (по-видимому) запускает командную строку, настроенную правильно для запуска GCC. Во-вторых, удалить двойные кавычки из папки GCC install bin, которую я добавил в переменную пути пользователя. Я попробовал это после того, как заметил партию файл не использует двойные кавычки вокруг пути установки bin.
Дополнительные Детали
Я случайно нашел пакетный файл во время просмотра дерева папок установки, пытаясь найти различные исполняемые файлы, которые не запускались (в соответствии с выходом-v). Я нашел некоторую информацию о MinGW wiki,http://www.mingw.org/wiki/Getting_Started, в разделах предостережения и параметры среды, это указывает, почему установщик MinGW не настраивает систему или путь пользователя для включения папки установки. Они, похоже, подтверждают, что пакетный файл предназначен для запуска командной строки, подходящей для запуска GCC из командной строки Windows.
в «дайте человеку рыбу, накормите его на день; научите человека рыбачить, избавьтесь от него на весь уик-энд» Вена,
g++ --help
показывает параметры компилятора. Опция g++ — v помогает:
-v Display the programs invoked by the compiler
просмотрите выходные данные для фиктивных путей. В моем случае исходная команда:
g++ -v "d:/UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"
сгенерированный выход, включая этот маленький драгоценный камень:
-iprefix c:olimexodsyagartoarm-none-eabibin../lib/gcc/arm-none-eabi/4.5.1/
что объясняет сообщение «Нет такого файла или каталога».
в «../lib/gcc/arm-none-eabi/ 4.5.1 / » сегмент исходит из встроенных спецификаций:
g++ -dumpspecs
у меня был очень длинный путь, и где-то там есть файл (не gcc.exe) но другой файл, этот gcc.exe получает доступ из пути..
поэтому, когда я очистил путь, он работал
C:MinGW>cd bin
C:MinGWbin>where gcc.exe
C:MinGWbingcc.exe
C:Perl64sitebingcc.exe
^^ таким образом, запуск gcc оттуда определенно запустит gcc ming.exe
C:MinGWbin>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:MinGWbin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
мой путь был огромен
C:MinGWbin>path
PATH=C:Windowssystem32;C:Windows;C:Windowssystem32wbem;C:P......
C:MinGWbin > путь / grep-io «ming»
у него не было мин там.
C:MinGWbin > Эхо мин / grep-io » мин»
Минг!—9—>
(и да, что grep работает..путь не есть мин есть)
очистка моего пути полностью, привел его к работе!
C:MinGWbin>set PATH=
C:MinGWbin>gcc file6.c
C:MinGWbin>
Итак, пока не ясно, что именно было на пути, который привел к столкновению. Какой каталог, какой файл.
обновление-
выше, кажется, правильно для меня, но добавить, это также не простой случай чего-то ранее на пути столкнулись.. потому что обычно текущий каталог имеет приоритет. И это происходит здесь, поскольку GCC — version показывает, что он запускает ming, а не один из них в конфликтующем каталоге. Так что есть что-то забавное, если конфликтующий каталог находится в пути) , нужно либо сделать .gcc или добавить . к началу пути или добавить c:MinGWbin перед любыми конфликтующими каталогами в пути. это так, даже когда вы находитесь в C:MinGWbin и вот странный. И когда он дает ошибку, он все еще работает gcc Ming, но (по какой-то причине) смотрит на конфликтующий каталог, как я вижу из process monitor. Здесь может быть больше ответа http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista в ссылке, упомянутой в самом ответе здесь
это бит Ming32..
глядя на Ming 64bit, вероятно, имеет ту же проблему, но я вижу, интересно, что он поставляется с bat-файл, который (разумно) фактически помещает каталог bin в терпкий путь. И похоже, что это стандартный способ правильной работы Ming gcc.
Code::blocks IDE (разумно) также помещает каталог bin в начале пути. Если вы запустите программу C, которая показывает переменные среды, вы увидите это.
у меня была та же проблема, но ни одно из перечисленных в настоящее время решений не помогло сначала попробовать.
-v опция не дала никаких дополнительных подсказок.
пришлось прибегнуть к procmon и чтобы иметь возможность найти корень проблемы.
сброс g++ активность файла процесса выявила многочисленные попытки найти cc1plus исполняемый файл по разным путям. Среди них были пути к старой версии GCC.
но эта старая версия жила отдельно папка и вообще не упоминалась из новой версии, которую я пытался запустить.
наконец, устаревший путь был найден в переменной среды system %PATH%.
После его удаления, новая версия работает без ошибок.
добавить E:MinGWbin до PATH переменной.
похоже, что есть несколько дистрибутивов выпуска для MinGW. Какой вам попробовать? Для записи я столкнулся с той же проблемой, что и OP, и дистрибутив, который я получил, был от TDM-GCC 4.5.1.
Я нашел дистрибутив MinGW здесь кажется, работает намного лучше и настраивает все правильно. Поэтому для тех, кто сталкивается с этой задержанной ошибкой «createprocess-no-such-file-or-directory» и не может заставить вещи работать, удалите существующий MinGW и попробуйте тот, который я связал вместо.
У меня была такая же проблема (я запускаю cygwin)
запуск оболочки через cygwin.летучая мышь не помог, но запуск снаряда через Мингшелл помог. Не совсем уверен, почему, но я думаю, что это связано с дополнительным слоем, который cygwin помещает между исполняющим скриптом и базовой файловой системой.
я запускал pip install из Cygwin виртуального env для установки Django sentry..
решение для меня-это просто:
-
когда вы сохраняете программу, скажем, ее имя привет.cpp положите его в папку, например,xxl сохраните вашу программу.
-
вырезать эту папку и поместить ее в папку bin mingw.
-
при вызове программы:
------ g++ xxlhi.cpp --------
эта проблема может возникнуть, если у вас есть разные версии программ.
например, у вас есть 1-летний gcc и вы хотите скомпилировать исходный код на C++. Если вы используете mingw-get установка g++, gcc и g++ внезапно будут разные версии, и вы, вероятно, окажетесь в этой ситуации.
под управлением mingw-get update и mingw-get upgrade решил этот вопрос для меня.
(ссылаясь на оригинальную проблему)
Сегодняшняя версия mingw (см. дату поста)
Все, что мне нужно было сделать, это установить путь в той же оболочке, в которой я бежал gcc.
Мне потребовался час, чтобы вспомнить, как установить DOS variables…
A:> set PATH=C:MinGWbin;
C:Program FilesImageMagick-6.8.0-Q16;
C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;
C:WINDOWSsystem32WindowsPowerShellv1.0;
C:Program FilesQuickTimeQTSystem
A:> gcc hi.c
У меня была такая же проблема, и я пробовал все без результата, что исправило проблему для меня, это изменение порядка путей библиотеки в переменной PATH. У меня был cygwin, а также некоторые другие компиляторы, поэтому между ними, вероятно, было какое-то столкновение. Что я сделал, так это положил C:MinGWbin; путь сначала перед всеми другими путями, и это исправило проблему для меня!
попробуйте поместить путь в системные переменные вместо ввода пользовательских переменных в переменные среды.
я получал это сообщение об ошибке, потому что я использовал MinGW-w64 и команды в <install path>bin У всех был странный префикс. Я попытался вызвать исполняемые файлы в каталогах «целевой псевдоним», а не в <install path>bin каталоги, что привело к еще большим проблемам. Это нет-нет согласно часто задаваемые вопросы. Тогда решение для меня заключалось в создании символических ссылок на все команды с префиксами. Я открыл командную строку с повышенными правами и использовал что-то вроде mklink gcc.exe x86_64-w64-mingw32-gcc.exe для каждого исполняемого, и теперь моя сборка работает.
хотя сообщение старое, у меня была та же проблема с mingw32 vers 4.8.1 на 2015/02/13. Компиляция с использованием 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/
Я загрузил и запустил эту «онлайн-установку». Конечно, в этом были недостающие файлы. Я изменил переменную моего пути и указал на папку «bin», содержащую исполняемый файл g++. Перезагрузившей. Установлен 64 бит Eclipse. Открыл Eclipse и программу «Hello World» c++, скомпилированную, выполненную и отлаженную должным образом.
Примечание: 64-битный установщик, кажется, по умолчанию для настроек UNIX. Почему установщик определит ОС??? Обязательно измените их.
Я провел целый вечер, занимаясь этим. Надеюсь, это кому-то поможет.
У меня была та же проблема.
У меня уже был компилятор g++, установленный через MinGW (пакет mingw32-gcc-g++) но мне нужен был компилятор C, поэтому я запустил mingw-get-setup.exe, где я смог его установить mingw32-базы пакет с компилятором.
увы! У меня была эта ошибка, когда я использую gcc для компиляции:
gcc: ошибка: createprocess: нет такого файла или каталога
то, что я сделал, все еще используя менеджер установки MinGW, я удалил пакеты компиляторов C и C++, а именно mingw32-базы и mingw32-gcc-g++ и удалить сам каталог c:mingw . Затем я повторил mingw-get-setup.exe, установлен mingw32-базы и вуаля, это сработало
compiling on windows #62
Comments
stg commented Sep 28, 2013
with a clean mingw, msys, arm-none-eabi, ruby install.
neatly compiles all the sources but runs into issues at linking.
seem to be related to the real-ld ruby shell script and -flto
even though most users are on linux, it seems a working windows environment is very close — and going the last mile would not be a bad thing.
The text was updated successfully, but these errors were encountered:
corecode commented Sep 28, 2013
I think a windows toolchain is important to have — it would be great if you could help with that, because I do not run windows and have no experience with it.
Do you use gcc-arm-embedded?
What is the error you observe?
stg commented Sep 28, 2013
Yes, I am using gcc-arm-embedded from Launchpad, but I also tried SAT with much less success (although I did not troubleshoot at all).
I have plenty experience using gcc toolchains on Windows, but very little setting them up so I’m not sure I am much use here — except for trying things and reporting back.
I’ve posted the complete make output including the error here: http://pastebin.com/G3KqXaHu (I’ve added -Wl,-debug to the link stage)
Removing -flto from the makefile still results in an error during make, but if I manually link without -flto I can get through the link stage and running make post-link will then produce a final 3k elf file (from usb-dfu).
stg commented Sep 28, 2013
Problem is indeed with finding real-ld.
Adding an executable to the same folder which in turn runs the script with parameter passing gets me past this error.
However, this instead results in an identical not found error, but for lto-wrapper — despite being a native executable, and being available at the specified location.
While I prefer when environments work clean out of a windows shell, perhaps I should give cygwin a shot as it typically has better support for things like running shell scripts linux style.
corecode commented Sep 28, 2013
I think we’re close, and @tralamazza had a fix for this: basically, the ruby interpreter is not executed for the real-ld script.
corecode commented Sep 28, 2013
for the record: error output:
tralamazza commented Sep 28, 2013
remove env from the shebang in real-ld
JamesNewton commented Apr 30, 2014
Any word on this? @corecode, does @tralamazza ‘s fix work for you?
stg commented May 1, 2014
Here’s a list of caveats and good to know’s for Windows that I’ve run into:
- Change the shebang (first line) of real-ld to #!/usr/bin/ruby
- Make sure your «gnu tools for arm embedded» is located in a folder without spaces and is in your PATH or you will likely run into problems. The GNU Tools for ARM Embedded installer defaults to a path with several spaces.
- Needless to say, you will also need ruby as well as build tools in your path (i use MinGWs MSYS).
The first two are both due to bugs in the MSYS build tools and may or may not affect other build environments.
For SWD programming, dfu-util with a libusb driver works fine.
If you on the other hand want VCP serial communication (such as for the swd-adapter program in /bootloader/ to program a mchck from another mchck, or just generic communication) it’s a bit trickier.
- First you need to make a winusb .inf file to match the VID/PID.
This needs to be installed at the «USB composite device» level, and not the interfaces that show up as named mchck devices or it will list as working, but any attempt to communicate will hang the port. - Then, the serialport gem used in ruby (for the mchck programming environment) has a «bug» where an API call fails for mchck virtual com ports that needs to be patched directly in the serialport gem source.
The better option here would be to modify the MCHCK CDC code to something closer to the USB identifier used by Arduinos, which is tried and tested to work flawlessly across the common platforms.
Источник
CreateProcess: нет такого файла или каталога
Я получаю эту ошибку всякий раз, когда я пытаюсь запустить GCC вне его каталога установки ( E:MinGWbin ).
Итак, допустим я в E:code и иметь файл с именем one.c . Бегущий: gcc one.c -o one.exe даст мне эту ошибку:
единственным обходным путем является переход в каталог установки, запуск gcc оттуда и указание всех других путей. Моя переменная окружающей среды Path содержит E:MinGWbin .
любые предложения по устранению этой проблемы? Я запуск Windows XP SP3.
24 ответов
его специально сказали, что вам нужно перезагрузиться после установки переменных среды в windows для migwin.
У меня была аналогичная проблема, вызванная не установкой компилятора C++. В моем случае я собирал .cpp-файлы для расширения Python, но компилятор сначала вызывается как c:mingwbingcc — . исполняемый.
внутренне, gcc.exe заметит, что его попросили скомпилировать .файл cpp. Он попытается вызвать g++.exe и сбой с тем же сообщением об ошибке:
gcc.exe: CreateProcess: нет такого файла или каталога
по данным код:: блоки wiki, вам необходимо добавить C:MinGWlibexecgccmingw32MinGW-Version на PATH . Нет необходимости перезапускать, но вам нужно открыть другой терминал, чтобы получить новейший PATH настройки.
для MinGW-w64 это libexecgccx86_64-w64-mingw32.7.0
У меня просто была эта проблема.
в моем случае проблема была связана с проблемами при загрузке пакетов для GCC. Программа mingw-get думала, что закончила загрузку, но это не так.
Я хотел обновить GCC, поэтому я использовал mingw-get, чтобы получить более новую версию. По какой-то причине mingw-get думал, что загрузка для определенного файла закончена, но это не так. Когда он пошел, чтобы извлечь файл, я думаю, он выдал ошибку (которую я даже не потрудился посмотреть-я просто запустите «mingw-get update && mingw-get install mingw32-gcc» и оставьте его там).
чтобы решить, я удалил gcc, выполнив «mingw-get remove mingw32-gcc» , а также удалил файл пакета (тот, который mingw-get не полностью загрузил), который был в папке кэша mingw («C:MinGWvarcachemingw-getpackages» в моей системе), затем снова запустил команду install. Он загрузил и установил недостающие части GCC (он не полностью загрузил пакет GCC-core).
Что решена моя проблема.
интересно, что mingw-get был достаточно умен, чтобы продолжить загрузку GCC-core даже после того, как я удалил файл пакета в папке кэша, а также удалил пакет mingw32-gcc.
Я думаю, что более фундаментальной проблемой было то, что, поскольку файлы GCC-core не были установлены, cc1 не было. И gcc использует cc1. Я предполагаю, что, когда gcc попытался запустить cc1, он использовал CreateProcess где-то, проходя путь cc1, который не был путем существующий файл. Таким образом, сообщение об ошибке.
у меня была точно такая же проблема.
после перепроверки моего PATH , Я понял, что установил оба Mingw (64 bit) и Cygwin (32 бит). Проблема в том, что оба Mingw и Cygwin есть g++ .
отключив пути Cygwin , ошибка исчезла.
Итак, это глупое сообщение об ошибке, потому что оно не говорит вам что файл, который он не может найти.
выполните команду еще раз с подробным флагом gcc -v чтобы увидеть, что gcc до.
в моем случае случилось так, что он пытался позвонить cc1plus . Я проверил, у меня его нет. Установил компилятор mingw на C++, а затем сделал.
получал то же сообщение об ошибке при попытке запуска из Cygwin со ссылками на установку mingw.
используя ту же установку mingw32-make-3.80.0-3.exe от http://www.mingw.org/wiki/FAQ и опция оболочки mingw из Start — > Programs — > на WinXP SP3 и gcc работает нормально.
эта проблема заключается в том, что вы используете материал суффикса верхнего регистра.C вместо строчных букв.c при компиляции с помощью Mingw GCC. Например, когда вам это нравится:
затем вы получите сообщение: gcc: CreateProcess: No such file or directory
но если вы это сделаете:
затем он работает. Я просто не знаю, почему.
У меня была такая же проблема, и ни одно из предложенных исправлений не работало для меня. Поэтому, хотя это старый поток, я думаю, что я мог бы также опубликовать свое решение, если кто-то еще найдет этот поток через Google(как и я).
для меня мне пришлось удалить MinGW / удалить папку MinGW и переустановить. После повторной установки он работает как шарм.
Я испытал аналогичную проблему. Первоначально добавление папки bin GCC в мой системный путь не решило проблему. Я нашел два решения.
первым было запустить пакетный файл, который я нашел в корне установки MinGW, mingwbuilds.летучая мышь. Он (по-видимому) запускает командную строку, настроенную правильно для запуска GCC. Во-вторых, удалить двойные кавычки из папки GCC install bin, которую я добавил в переменную пути пользователя. Я попробовал это после того, как заметил партию файл не использует двойные кавычки вокруг пути установки bin.
Я случайно нашел пакетный файл во время просмотра дерева папок установки, пытаясь найти различные исполняемые файлы, которые не запускались (в соответствии с выходом-v). Я нашел некоторую информацию о MinGW wiki,http://www.mingw.org/wiki/Getting_Started, в разделах предостережения и параметры среды, это указывает, почему установщик MinGW не настраивает систему или путь пользователя для включения папки установки. Они, похоже, подтверждают, что пакетный файл предназначен для запуска командной строки, подходящей для запуска GCC из командной строки Windows.
в «дайте человеку рыбу, накормите его на день; научите человека рыбачить, избавьтесь от него на весь уик-энд» Вена,
показывает параметры компилятора. Опция g++ — v помогает:
просмотрите выходные данные для фиктивных путей. В моем случае исходная команда:
сгенерированный выход, включая этот маленький драгоценный камень:
что объясняет сообщение «Нет такого файла или каталога».
в «../lib/gcc/arm-none-eabi/ 4.5.1 / » сегмент исходит из встроенных спецификаций:
у меня был очень длинный путь, и где-то там есть файл (не gcc.exe) но другой файл, этот gcc.exe получает доступ из пути..
поэтому, когда я очистил путь, он работал
^^ таким образом, запуск gcc оттуда определенно запустит gcc ming.exe
компиляция я получил эту ошибку
мой путь был огромен
C:MinGWbin > путь / grep-io «ming»
у него не было мин там.
C:MinGWbin > Эхо мин / grep-io » мин» Минг!—9—>
(и да, что grep работает..путь не есть мин есть)
очистка моего пути полностью, привел его к работе!
Итак, пока не ясно, что именно было на пути, который привел к столкновению. Какой каталог, какой файл.
обновление-
выше, кажется, правильно для меня, но добавить, это также не простой случай чего-то ранее на пути столкнулись.. потому что обычно текущий каталог имеет приоритет. И это происходит здесь, поскольку GCC — version показывает, что он запускает ming, а не один из них в конфликтующем каталоге. Так что есть что-то забавное, если конфликтующий каталог находится в пути) , нужно либо сделать .gcc или добавить . к началу пути или добавить c:MinGWbin перед любыми конфликтующими каталогами в пути. это так, даже когда вы находитесь в C:MinGWbin и вот странный. И когда он дает ошибку, он все еще работает gcc Ming, но (по какой-то причине) смотрит на конфликтующий каталог, как я вижу из process monitor. Здесь может быть больше ответа http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista в ссылке, упомянутой в самом ответе здесь
глядя на Ming 64bit, вероятно, имеет ту же проблему, но я вижу, интересно, что он поставляется с bat-файл, который (разумно) фактически помещает каталог bin в терпкий путь. И похоже, что это стандартный способ правильной работы Ming gcc.
Code::blocks IDE (разумно) также помещает каталог bin в начале пути. Если вы запустите программу C, которая показывает переменные среды, вы увидите это.
у меня была та же проблема, но ни одно из перечисленных в настоящее время решений не помогло сначала попробовать.
-v опция не дала никаких дополнительных подсказок.
пришлось прибегнуть к procmon и чтобы иметь возможность найти корень проблемы.
сброс g++ активность файла процесса выявила многочисленные попытки найти cc1plus исполняемый файл по разным путям. Среди них были пути к старой версии GCC.
но эта старая версия жила отдельно папка и вообще не упоминалась из новой версии, которую я пытался запустить.
наконец, устаревший путь был найден в переменной среды system %PATH%. После его удаления, новая версия работает без ошибок.
добавить E:MinGWbin до PATH переменной.
похоже, что есть несколько дистрибутивов выпуска для MinGW. Какой вам попробовать? Для записи я столкнулся с той же проблемой, что и OP, и дистрибутив, который я получил, был от TDM-GCC 4.5.1.
Я нашел дистрибутив MinGW здесь кажется, работает намного лучше и настраивает все правильно. Поэтому для тех, кто сталкивается с этой задержанной ошибкой «createprocess-no-such-file-or-directory» и не может заставить вещи работать, удалите существующий MinGW и попробуйте тот, который я связал вместо.
У меня была такая же проблема (я запускаю cygwin)
запуск оболочки через cygwin.летучая мышь не помог, но запуск снаряда через Мингшелл помог. Не совсем уверен, почему, но я думаю, что это связано с дополнительным слоем, который cygwin помещает между исполняющим скриптом и базовой файловой системой.
я запускал pip install из Cygwin виртуального env для установки Django sentry..
решение для меня-это просто:
когда вы сохраняете программу, скажем, ее имя привет.cpp положите его в папку, например,xxl сохраните вашу программу.
вырезать эту папку и поместить ее в папку bin mingw.
при вызове программы:
эта проблема может возникнуть, если у вас есть разные версии программ.
например, у вас есть 1-летний gcc и вы хотите скомпилировать исходный код на C++. Если вы используете mingw-get установка g++ , gcc и g++ внезапно будут разные версии, и вы, вероятно, окажетесь в этой ситуации.
под управлением mingw-get update и mingw-get upgrade решил этот вопрос для меня.
(ссылаясь на оригинальную проблему)
Сегодняшняя версия mingw (см. дату поста)
Все, что мне нужно было сделать, это установить путь в той же оболочке, в которой я бежал gcc .
Мне потребовался час, чтобы вспомнить, как установить DOS variables .
У меня была такая же проблема, и я пробовал все без результата, что исправило проблему для меня, это изменение порядка путей библиотеки в переменной PATH. У меня был cygwin, а также некоторые другие компиляторы, поэтому между ними, вероятно, было какое-то столкновение. Что я сделал, так это положил C:MinGWbin; путь сначала перед всеми другими путями, и это исправило проблему для меня!
попробуйте поместить путь в системные переменные вместо ввода пользовательских переменных в переменные среды.
я получал это сообщение об ошибке, потому что я использовал MinGW-w64 и команды в bin У всех был странный префикс. Я попытался вызвать исполняемые файлы в каталогах «целевой псевдоним», а не в bin каталоги, что привело к еще большим проблемам. Это нет-нет согласно часто задаваемые вопросы. Тогда решение для меня заключалось в создании символических ссылок на все команды с префиксами. Я открыл командную строку с повышенными правами и использовал что-то вроде mklink gcc.exe x86_64-w64-mingw32-gcc.exe для каждого исполняемого, и теперь моя сборка работает.
хотя сообщение старое, у меня была та же проблема с mingw32 vers 4.8.1 на 2015/02/13. Компиляция с использованием 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/ Я загрузил и запустил эту «онлайн-установку». Конечно, в этом были недостающие файлы. Я изменил переменную моего пути и указал на папку «bin», содержащую исполняемый файл g++. Перезагрузившей. Установлен 64 бит Eclipse. Открыл Eclipse и программу «Hello World» c++, скомпилированную, выполненную и отлаженную должным образом.
Примечание: 64-битный установщик, кажется, по умолчанию для настроек UNIX. Почему установщик определит ОС. Обязательно измените их.
Я провел целый вечер, занимаясь этим. Надеюсь, это кому-то поможет.
У меня была та же проблема.
У меня уже был компилятор g++, установленный через MinGW (пакет mingw32-gcc-g++) но мне нужен был компилятор C, поэтому я запустил mingw-get-setup.exe, где я смог его установить mingw32-базы пакет с компилятором.
увы! У меня была эта ошибка, когда я использую gcc для компиляции:
gcc: ошибка: createprocess: нет такого файла или каталога
Источник