Solving the 8192 Character Command Line Limit on Windows

Posted on March 29, 2015 by Erich Styger

There is a really annoying issue with using command line tools on Windows: the maximum length of the command line passed to cmd.exe is 8192 characters (see http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx). So you think this is not a problem for you, as you would not pass such a long command line to cmd.exe (the DOS shell under Windows)? Well, if you are using Eclipse (as I do) which generates make files (which is the normal way), then the cmd.exe very likely is involved to call the compiler/linker/etc, indirectly with the usage of make.exe. Compiling files is usually not a problem as it does not hit that 8192 limit. However, it is likely that link phase will end up with an error:

Error in the Problems View

If you have such a problem, there is a solution ….

Failure to Link?

Looking at the Console output, it is clearly the link phase which failed:

Linker failed because of 8192 character limit

So what happened? I’m using source files with a rather long directory path, and many of them (e.g. building the CMSIS library, see “Tutorial: Using the ARM CMSIS Library“). Because that library/project has many, many files which need to be linked, it will fail at the link phase. In my above test example I have a command line length passed to the linker which is 12316 characters long!

The error might be a strange one, maybe saying something like it cannot find or execute an object file. Because the command line gets cut somewhere, the error message reported usually does not give a clear clue.

Command Line Length Limit

The problem is not the problem of Eclipse: it is rather the problem of make how much it accepts on the command line and long the command line to the gcc compiler and linker can be. The problem can be easly reproduce with my DIY toolchain and is present in other vendor toolchains like the Freescale Kinetis Design Studio (tried with v2.0.0) on Windows.

💡 CodeWarrior for MCU solves that problem with a custom build tools integration: instead of passing the full set of arguments on the command line, it uses files with the options/commands in it. So it passes the options to the called process with pointing to a file. Unfortunately this is not present in the widely used GNU ARM Eclipse plugins (see support request #25 and support request #32).

Oh yeah, I hear now already the voices singing: “Dude, it’s your fault, why are you using Windows? Use Linux!” because this problem does not exist on Linux. Oh well, do not get me there 😉

The obvious solution is to keep the command line as short as possible, especially for the linker:

Use short directory names
Use short file names
Reduce the command line length with using relative paths instead of absolute file paths
If this does not help: build part of the application as a library and then link the library with the final application

Needless to say that this is all very time consuming and just a workaround for the problem. The solution is to use the GNU ARM Eclipse Build Tools package instead.

GNU ARM Eclipse Build Tools

Luckily, there is now a solution available for Windows, thanks to the Liviu and the GNU ARM Eclipse work :-). The solution is available from the version v2.6.1 or later of the GNU ARM Eclipse Plugins build tools, and the release notes reads:

“The new Build Tools v2.3 include a better shell version, instead of the Windows cmd.exe, so the annoying 8K limit on command line lengths was removed.”

Oh, wow! So this is the solution is to use these build tools, and then that 8192 character command line limit should be gone? Yes, it is :-)!

Installing the Solution

The latest build (v2.4 at the time of this writing) is available from https://sourceforge.net/projects/gnuarmeclipse/files/Build%20Tools/.

GNU ARM Eclipse Build Tools

Download the setup executable and run it.

GNU ARM Eclipse Build Tools Installer

On my machine, the build tools get installed into

C:\Program Files (x86)\GNU ARM Eclipse\Build Tools\2.4-201503242026\bin

GNU ARM Eclipse Build Tools Installed

Now make sure that these tools are used instead of the ones with the 8192 command line character limit. For Kinetis Design Studio v2.0.0, the build tools are located in these sub folders:

make.exe is in <kds_2.0.0>\toolchain\bin
echo.exe and rm.exe are in <kds_2.0.0>\bin

Rename the existing make.exe, rm.exe and echo.exe so you have a backup. Then copy the files from the GNU ARM Eclipse build tools into the KDS bin folder:

GNU ARM Eclipse Build Tools in KDS

Because I have renamed the existing make.exe, rm.exe and echo.exe, they are not found any more and the new versions are used instead with the sh.exe which fixes that annoying Windows problem. And if I do a build now with my long command line, it does works :-):

Success building with GNU and very long command line

Summary

Windows (better, cmd.exe) has a command line length limit of 8192 characters. The GNU ARM Eclipse build tools provided by Liviu have fixed this with a new sh.exe. Using the GNU ARM Eclipse build tools allowed me overcome that Windows limit. The fix is easy to apply: replace the limited cmd.exe based tools with teh GNU ARM Eclipse ones which use the sh.exe.

Happy Shelling 🙂

PS: Liviu, you probably read this, and I know you are using Mac OS, and you are not a fan of Windows environment for good reasons. On behalf of the Windows user community: THANK YOU, THANK YOU, THANK YOU!

81 thoughts on “Solving the 8192 Character Command Line Limit on Windows”

Liviu Ionescu (ilg) on March 29, 2015 at 19:23 said:

You’re welcome! 🙂

LikeLiked by 1 person

Reply ↓
- Niranjan on November 13, 2015 at 12:38 said:
  
  Hi Liviu
  
  I did changed the exe’s at path
  C:\Freescale\KDS_3.0.0\bin
  
  but I still get the same problem, “no such file or directory”
  if I move that file to different directory where the directory path character reduces, it works fine.
  
  am i missing anything here.
  
  LikeLike
  
  Reply ↓
  - Liviu Ionescu (ilg) on November 13, 2015 at 12:45 said:
    
    I’m not sure I can follow you. what path did you change?
    
    I don’t know in KDS, but in the original GNU ARM Eclipse plug-ins, you need to install the latest Windows Build Tools and then tell the plug-ins where these tools are. once you do this, the Windows cmd.exe 8192 chars limitation should no longer be a problem, since my package includes not only make.exe, but also sh.exe, so no need for the limited cmd.exe.
    
    LikeLike
    
    Reply ↓
  - Niranjan on November 13, 2015 at 12:53 said:
    
    I downloaded “gnuarmeclipse-build-tools-win32-2.6-201507152002-setup.exe” and installed it in windows.
    
    now I have gnu arm at below path
    C:\Program Files (x86)\GNU ARM Eclipse
    
    I copied
    make.exe, rm.exe, busybox.exe, echo.exe, sh.exe, intl.dll
    from below path
    C:\Program Files (x86)\GNU ARM Eclipse\Build Tools\2.6-201507152002\bin
    
    to KDS directory
    
    C:\Freescale\KDS_3.0.0\bin
    
    LikeLike
    
    Reply ↓
  - Liviu Ionescu (ilg) on November 13, 2015 at 13:00 said:
    
    I don’t know how KDS manages the PATH, apparently it should work, but it looks like we are missing something. 😦
    
    LikeLike
    
    Reply ↓
Liviu Ionescu (ilg) on March 29, 2015 at 19:55 said:

One small comment: the latest version of the managed build plug-in also adds a mechanism to manage the path of the build tools (see Preferences -> C/C++ -> Build -> Global Tools Paths and Workspace Tools Paths). If you run the build tools setup, regardless where you decide to install the package, there are some keys written to the Windows Registry, and the plug-in will automatically add the correct path to the build path.

All recent GNU ARM Eclipse tools packages (Build Tools, OpenOCD, and the under development QEMU) allow to install multiple versions of the same package, and the Windows Registry keys (or some folder search on other platforms) are able to easily identify the tools location, and finally adjust the plug-in configuration, either automatically or with minimal effort.

I don’t know how this fits into the KDS current structure, but for plain GNU ARM Eclipse installations, I highly recommend to use this mechanism.

LikeLike

Reply ↓
- Erich Styger on March 30, 2015 at 07:45 said:
  
  Hi Liviu,
  at least KDS v2.0.0 adds the toolchain and bin path in front of the PATH variable, so is not as flexible as your generic approach. I agree that modification of the PATH is not needed and not something which should be done, and this should be removed.
  
  LikeLike
  
  Reply ↓
barteroff on March 29, 2015 at 20:30 said:

How about read command-line options from file?
@file option https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html

LikeLike

Reply ↓
- Erich Styger on March 30, 2015 at 05:31 said:
  
  Yes, but if using the Eclipse build system, this would have to be generated by the plugins, which is not the case.
  
  LikeLike
  
  Reply ↓
- Liviu Ionescu (ilg) on March 30, 2015 at 08:24 said:
  
  The GNU ARM Eclipse managed build plug-in uses the code from CDT to generate the make files, and this specific CDT code is not particularly friendly with plug-ins that want to extend it. In practical terms, extending is possible only by completely rewriting the classes, which is not practical, since keeping in sync with future CDT versions becomes too manually intensive.
  
  So… ‘no can do’… 😦
  
  LikeLike
  
  Reply ↓
Mike on March 30, 2015 at 21:31 said:

Minor typo, the above says:

2. echo.exe and rm.exe are in \toolchain\bin

but they are in \bin.

LikeLike

Reply ↓
- Erich Styger on March 31, 2015 at 07:55 said:
  
  Good catch, thanks, fixed now 🙂
  
  LikeLike
  
  Reply ↓
Bill Lewis on March 31, 2015 at 15:41 said:

I remember when I was fighting 128 character command lines in MS-DOS!
-Bill

LikeLike

Reply ↓
tattoomike7488 on March 31, 2015 at 20:05 said:

Hey guys, looks like “clearn project” (rm) is still crapping on when there are a lot of .o files.

rm -rf ./Source/Generated_Code/CD.o ./Source/Generated_Code/CS.o ./Source/Generated_Code/Events.o ./Source/Generated_Code/LCDPort.o
****** CLIPPED TONS OF OUTPUT HERE *****
./Source/Config/LCD_X_8080_8.d libSegger-GUI.a, …) failed.
make (e=87): The parameter is incorrect.

LikeLike

Reply ↓
Mike on April 1, 2015 at 00:11 said:

Make isn’t working for me either:

arm-none-eabi-ar -r “libemWin_V528b.a” ./Sources/Generated_Code/CD.o ./Sources/Generated_Code/CS.o ./Sources/Generated_Code/Events.o ./Sources/Generated_Code/LCDPort.o ./Sources/Generated_Code/POR_DIS.o ./Sources/Generated_Code/RD.o ./Sources/Generated_Code/RST.o
..
..
..
./Sources/GUI/ConvertMono/GUICC_8.o ./Sources/Config/GUIConf.o ./Sources/Config/GUI_X.o ./Sources/Config/LCDConf.o ./Sources/Config/LCD_X_8080_8.o, …) failed.
make (e=87): The parameter is incorrect.

make: *** [libemWin_V528b.a] Error 87

LikeLike

Reply ↓
- Erich Styger on April 1, 2015 at 08:26 said:
  
  Hi Mike,
  are you sure that the new make is used? Have you removed/renamed the one in the toolchain/bin? I think that on your machine still the ‘old’ tools are called.
  
  LikeLike
  
  Reply ↓
  - Steven Bauman on March 14, 2016 at 21:45 said:
    
    Hi guys!
    
    With your solution Eric, now i am able to build my project, but the clean function does not work. I did everything exactly as you described, and i used the latest GNU ARM Eclipse Build Tools.
    
    Maybe do you have any other idea, what can be the problem?
    
    Thanks for any advice in advance.
    
    Bye,
    Steven
    
    LikeLike
    
    Reply ↓
  - Andrew on April 27, 2016 at 14:06 said:
    
    I’m also running into a problem with clean (others have mentioned it above as well). If I manually delete the debug folder, I can do a build from scratch no problem, but clean fails. I’ve tried copying all of the build tools into the proper folder, and I’ve also tried pointing to them in an external location using the “Tools Path” feature under project properties. No matter what I do I get the following error:
    
    make (e=87): The parameter is incorrect.
    
    make: [clean] Error 87 (ignored)
    makefile:197: recipe for target ‘clean’ failed
    
    But, if I manually edit the makefile and remove some of the .mk includes, clean works again.
    
    Any ideas?
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 28, 2016 at 06:57 said:
      
      Hi Andrew,
      I had that problem only once or twice, and it disappeared (not sure why).
      Could it be that you have another rm present in your PATH settings (on system level)?
      
      Erich
      
      LikeLike
  - Andrew on April 28, 2016 at 13:00 said:
    
    My Windows system path has only “C:\Windows\system32” in it (no rm in there). In my project settings PATH variable, the path to the GNU ARM Eclipse build tools folder is the first thing listed.
    
    It looks like the right RM is being called:
    
    process_begin: CreateProcess(C:\Freescale\2.6-201507152002\bin\rm.exe, rm -rf V2_MQX_PEx.siz
    
    But before it even gets to that, I get the error:
    
    makefile:197: recipe for target ‘clean’ failed
    
    Apparently this is the line where make fails:
    
    -$(RM) $(SECONDARY_SIZE)$(C++_DEPS)$(OBJS)$(C_DEPS)$(ASM_DEPS)$(CC_DEPS)$(CPP_DEPS)$(CXX_DEPS)$(C_UPPER_DEPS)$(S_UPPER_DEPS) V2_MQX_PEx.elf
    
    LikeLike
    
    Reply ↓
  - Andrew on April 28, 2016 at 13:19 said:
    
    One more thing,
    
    I tried changing the RM line in the makefile and split it up like this:
    
    clean:
    -$(RM) $(SECONDARY_SIZE)
    -$(RM) $(C++_DEPS)$(OBJS)
    -$(RM) $(C_DEPS)
    -$(RM) $(ASM_DEPS)
    -$(RM) $(CC_DEPS)
    -$(RM) $(CPP_DEPS)
    -$(RM) $(CXX_DEPS)
    -$(RM) $(C_UPPER_DEPS)
    -$(RM) $(S_UPPER_DEPS)
    -$(RM) V2_MQX_PEx.elf
    
    It works fine now. This is not a great solution going forward, but it does hint at a lingering character limit issue.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 28, 2016 at 16:13 said:
      
      Hi Andrew,
      I come to the conclusion that the make (http://gnuarmeclipse.github.io/windows-build-tools/releases/) is able to deal with longer arguments (>8192), but the rm command still fails with that long command line. So the easy workaround is to delete the output folder (e.g. ‘debug’) instead let rm remove all object files. I have filed a bug report (https://github.com/gnuarmeclipse/windows-build-tools/issues/3), be free to add any more details.
      thanks!
      
      LikeLike
  - Andrew on April 28, 2016 at 17:23 said:
    
    Eric,
    
    Thanks for your help with this, I will followup with the bug report if I have anything more to add.
    
    Thanks again!
    
    LikeLike
    
    Reply ↓
  - Andrew on April 28, 2016 at 17:52 said:
    
    Oops, Erich*, excuse the spelling mistake.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 28, 2016 at 18:01 said:
      
      No worries, both works for me 🙂
      
      LikeLike
Mike on April 1, 2015 at 00:49 said:

There are about 900 files in my project, so seems I have broken past some other barrier?

LikeLike

Reply ↓
- Liviu Ionescu (ilg) on April 1, 2015 at 08:00 said:
  
  Did you install the build tools using the setup? Can you confirm that make.exe and sh.exe are in a folder named bin?
  
  LikeLike
  
  Reply ↓
  - Mike on April 2, 2015 at 19:57 said:
    
    Hi Liviu,
    
    Yes, I installed the build tools using setup, renamed the old ones, and copied the new ones over exactly as described in the instructions.
    
    Yes, make.exe and sh.exe are in C:/Freescale/KDS_2.0.0/bin
    
    I think I may know the problem: I am building a static library, not an executable, so I’m calling the archiver not linker.
    
    Have you tried your new build tools for static libraries?
    
    LikeLike
    
    Reply ↓
    - Liviu Ionescu (ilg) on April 2, 2015 at 20:04 said:
      
      unless AR has some limitations, there should be no differences, make.exe uses sh.exe to run a child process.
      
      LikeLike
  - Mike on April 2, 2015 at 20:04 said:
    
    Also this message is displayed over and over:
    
    c:/freescale/kds_2.0.0/eclipse/../bin/sh: echo.: not found
    
    My global toolchain path is set to:
    
    ${eclipse_home}/../toolchain/bin
    
    Is that correct?
    
    LikeLike
    
    Reply ↓
    - Liviu Ionescu (ilg) on April 2, 2015 at 20:12 said:
      
      if the new echo.exe is present in the bin folder, than you have a path problem. you should use all new executables.
      
      personally I would recommend to leave them where the setup installed them, remove them from any other location, and configure the global build tools path there. (the preferences windows to configure the build tools path is available only in the latest plug-in version, you might need to update).
      
      LikeLike
  - Mike on April 2, 2015 at 20:42 said:
    
    Hi Liviu,
    
    I have installed the latest updates for KDS, is that what you’re talking about?
    
    How do I change the build tools path?
    
    Thanks for your help
    
    LikeLike
    
    Reply ↓
    - Liviu Ionescu (ilg) on April 2, 2015 at 20:46 said:
      
      I don’t know for KDS, the latest plug-ins are available as described at gnuarmeclipse.livius.net/blog/. The Global Tools paths can be configured as shown at gnuarmeclipse.livius.net/blog/2015/02/28/version-2-6-1-201502281154-released/
      
      LikeLike
Kris S. on April 20, 2015 at 19:43 said:

This was extremely helpful, I just ran into this exact issue with KDS and luckily found your posting.

Thanks!

LikeLike

Reply ↓
Pingback: Comparing CodeWarrior with Kinetis Design Studio | MCU on Eclipse
dmatsumoto on May 20, 2015 at 20:19 said:

This is super helpful, thank you for sharing. It worked great with KDS 2.0, and I am currently trying it out with KDS 3.0. Seems to be fine there, too!

LikeLike

Reply ↓
mauroansa on May 21, 2015 at 20:13 said:

This was very helpful, thank you. It worked with KDS 3.0 also

LikeLike

Reply ↓
- Erich Styger on May 21, 2015 at 21:26 said:
  
  thanks for confirmation. Yes, this should be usable for any Windows Eclipse based gcc tools, including KDS v1.x, v2.x and V3.x
  
  LikeLike
  
  Reply ↓
  - Liviu Ionescu (ilg) on May 21, 2015 at 21:32 said:
    
    Yes, this should work for any Eclipse build plug-ins, not only the GNU ARM Eclipse managed builds, as long as the **sh.exe** executable is available in the same folder as **make.exe** and the folder is named **bin**.
    
    LikeLike
    
    Reply ↓
AlexC on June 30, 2015 at 13:03 said:

I have the same problem with these tools (I’ve installed gnuarmeclipse-build-tools-win32-2.4-201503242026-setup.exe):

~/alexandruc_win_project $ echo $SHELL
/bin/sh
~/alexandruc_win_project $ which make
C:/Program Files (x86)/GNU ARM Eclipse/Build Tools/2.4-201503242026/bin/make.exe
~/alexandruc_win_project $ make
Building file: ../Inventory/Inventory_CeraOS.cpp
Invoking: GCC C++ Compiler
….
The command line is too long.

Am I doing something wrong ?

LikeLike

Reply ↓
- Erich Styger on June 30, 2015 at 13:13 said:
  
  Can you check your PATH if really it is using the updated GNU ARM Eclipse binaries?
  
  LikeLike
  
  Reply ↓
  - AlexC on June 30, 2015 at 15:07 said:
    
    I’ve put the path to the ARM binaries at the start of the PATH variable.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on June 30, 2015 at 15:20 said:
      
      Hi Alex,
      hmm, I can tell that for me using these new tools removed the problem.
      But your command line looks like you are using something else than plain Windows cmd somehow?
      
      LikeLike
Randy Hermes on August 27, 2015 at 16:33 said:

I ran into one issue after installing the new build tools – the new make only accepts forward slashes (/), not back slashes (\). If you have build variables defined in your KDS project you will have to edit them and change “\” to “/”.
Installation fixed the linker issue but would not build a clean project.

LikeLike

Reply ↓
- Erich Styger on August 28, 2015 at 06:59 said:
  
  Good point! I have not been running into this as for a long time I started to use forward slashes in my project settings whenever possible to keep things in sync with Linux. And the wizard in Eclipse seems to use forward slashes whenever possible too.
  
  LikeLike
  
  Reply ↓
Yaran on November 11, 2015 at 16:06 said:

Hi, I am running KDS3.0 on win8. I ran into this building error and downloaded 64 bits version.
It always crushed when I try to build project. Any solution for that??

LikeLike

Reply ↓
- Erich Styger on November 11, 2015 at 17:24 said:
  
  Hi Yaran,
  I have not seen this with Windows 7 and 64bit. Same problem if you use the 32bit version of the tools?
  
  LikeLike
  
  Reply ↓
  - Yaran on November 11, 2015 at 17:45 said:
    
    Yeah, it produced the same issue. I also tried to modified the compatibility to win7.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on November 11, 2015 at 17:51 said:
      
      is the compiler crashing or the make? What if you use a DOS shell to run the make/rm/etc?
      
      LikeLike
T Hall on December 29, 2015 at 21:46 said:

Followed the instructions to the letter. Now it looks like anything I try to do with make – either clean or build, simply doesn’t do anything. Not sure what is missing here but this is not working out as a solution. I am on KDS 2.0.0 and downloaded GNU ARM Eclipse Build Tools 2.6-201507152002 😦

LikeLike

Reply ↓
- Erich Styger on December 30, 2015 at 07:50 said:
  
  I don’t know why it should not work with KDS v2.0.0. But v2.0.0 is very old. Is there a reason why not using v3.0.0? V3.0.0 comes with a much better GNU tool. I recommend that you install 3.0.0 (you can keep 2.0.0 installed, just in case).
  
  LikeLike
  
  Reply ↓
  - Tharon Hall on December 30, 2015 at 15:53 said:
    
    Very simple. We are nearing production and it is late in the game to make a tool change unless absolutely necessary. it would mandate a lot of regression testing to confirm the new tools have not introduced new problems. (Tool updates are often a trade off between different bugs, as opposed to the elimination of all bugs, but your mileage may vary.)
    
    LikeLike
    
    Reply ↓
    - Erich Styger on December 30, 2015 at 17:13 said:
      
      Ok, understood, that’s a very good reason to keep things frozen.
      
      LikeLike
    - Tharon Hall on December 30, 2015 at 17:16 said:
      
      Comes from years of (bad) experience. 😉
      
      LikeLike
  - Liviu Ionescu (ilg) on December 30, 2015 at 17:23 said:
    
    Generally each GNU ARM Eclipse binary packages installs in a separate folder, exactly to allow strict environments to return to a desired version in case new ones break any compatibility.
    
    LikeLike
    
    Reply ↓
Salva on January 4, 2016 at 12:31 said:

Hi I’ve just tried with KDS3.0 & SDK 1.3.0: it works, but you have to copy ALL files into “C:\Freescale\KDS_3.0.0\bin” (and not only echo.exe, rm.exe and make.exe), othervise it doesn’t compile/link.
However great job,
thanks so much

LikeLike

Reply ↓
- Erich Styger on January 4, 2016 at 12:59 said:
  
  Yes, it seems that with the most recent release more files are necessary, thanks for pointing this out.
  
  LikeLike
  
  Reply ↓
  - Liviu Ionescu (ilg) on January 4, 2016 at 19:47 said:
    
    if you mean the DLLs in the original GNU ARM Eclipse package, yes, they are present for a reason, and you need to copy all of them.
    
    LikeLike
    
    Reply ↓
- Tharon Hall on January 6, 2016 at 21:18 said:
  
  Yes! I had to also copy the .dll files. I copied them into both /bin locations to be safe, but it appears everything is working fine so far now. 🙂
  
  LikeLike
  
  Reply ↓
  - Mike Ihm on April 13, 2016 at 21:55 said:
    
    Hi Eric,
    
    Had an odd linker issue today …”/Generate_Code/hardware_init.o: No such file or directory”. Using KSDK 1.3.0, PE, MQX_Standard and KDS 3.0.0.
    
    The solution you described here indeed fixed the problem! Thank you!
    
    LikeLike
    
    Reply ↓
    - Erich Styger on April 14, 2016 at 08:08 said:
      
      Hi Mike,
      yes, this one was a nasty issue to identify. The good news is that the latest KDS v3.2.0 released in March this year has this fix included, see https://mcuoneclipse.com/2016/04/02/nxp-kinetis-design-studio-v3-2-0/
      
      Erich
      
      LikeLike
Pingback: NXP Kinetis Design Studio v3.2.0 | MCU on Eclipse
Sunit Agrawal on June 3, 2016 at 16:25 said:

After making the changes and not using Command Line, now I have another issue with createProcessFunction() in Windows which has limitation of 32K characters.

I change the builder to external builder and selected the installed tools path in Builder Path Configuration.

Am I doing something wrong?

If no, is there a patch around it.

LikeLike

Reply ↓
- Erich Styger on June 3, 2016 at 16:35 said:
  
  I’m using External Builder setting too, and it works fine. Are you using Kinetis Design Studio V3.2.0? If not, you can give that one a try as it comes with the binaries included and works fine for me. Except that the ‘clean’ operation does not work with >8192 characters.
  
  LikeLike
  
  Reply ↓
Pingback: Tips for Making Copy of Eclipse CDT Projects Easier | MCU on Eclipse
Jason S. on August 18, 2017 at 22:47 said:

Hi Erich,

I am running into the ‘rm’ length issue. The ‘make’ command works. I am using the GNU ARM Eclipse build tools. I saw that you posted an issue to GNU MCU Eclipse site, but there hasn’t been any activity since 2016. We use the auto-generated makefile option. Deleting the folder in Windows Explorer is a really clunky solution to clean. Another workaround would be to call a post-build script that opens the makefile, finds the “rm” command, and then replaces all arguments that it calls into individual “rm” commands. Do you know of an easy way to build such a script?

LikeLike

Reply ↓
- Liviu Ionescu (ilg) on August 19, 2017 at 01:48 said:
  
  > there hasn’t been any activity since 2016
  
  the makefile is generated by CDT, the plug-ins do not have a way of change the way rm is processed (except rewriting the entire generator).
  
  LikeLike
  
  Reply ↓
- Erich Styger on August 19, 2017 at 09:44 said:
  
  I was thinking that maybe a fix would be needed for rm similar what has been done for make (but not sure if this is really feasible).
  For me deleting the build output folder (manually) is what worked so far. But I think you could use the pre-build step (with a build target) to delete the folder?
  
  LikeLike
  
  Reply ↓
  - Liviu Ionescu (ilg) on August 19, 2017 at 09:48 said:
    
    > a fix would be needed for rm similar what has been done for make (but not sure if this is really feasible).
    
    you can test if this is feasible by replacing rm with a script to iterate all arguments and delete them one by one.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on August 19, 2017 at 09:54 said:
      
      good idea!
      
      LikeLike
- Jason S. on August 25, 2017 at 19:52 said:
  
  We were able to create a script that opens the makefile, finds the line where the rm command is issued, parses all the objects in the rm command, and then writes individual rm commands for each object. The script resides in the “Debug” folder for now since it looks in its current directory for the makefile. We then added a post-build instruction to call the executable. We can now successfully use the “Clean” button in the IDE.
  
  LikeLike
  
  Reply ↓
  - Andrew on August 25, 2017 at 19:57 said:
    
    Great idea Jason! Would you be willing to share that script?
    
    LikeLike
    
    Reply ↓
armink on January 13, 2018 at 15:37 said:

Hi Erich,

The GNU MCU Eclipse also has same Command Line Limit problem(make (e=87):) on win10.

I using Eclipse Version: Oxygen.1a Release (4.7.1a)，GNU MCU Eclipse Windows Build Tools v2.10-20180103.

Is there any other solution?

LikeLike

Reply ↓
- Erich Styger on January 13, 2018 at 16:12 said:
  
  No, to my knowledge there is no other solution. Well, another solution would be to change Eclipse CDT and the build integration to use external files for the list of includes (as in CodeWarrior), but that is very unlikely to happen for CDT.
  
  LikeLike
  
  Reply ↓
  - Armink on January 13, 2018 at 16:18 said:
    
    Thx for your reply;)
    
    LikeLike
    
    Reply ↓
Armink on January 13, 2018 at 16:04 said:

my problem is case by project clean. link is OK.

LikeLike

Reply ↓
- Erich Styger on January 13, 2018 at 16:13 said:
  
  Yes, ‘clean’ uses a slightly different approach, and that problem is not solved for clean. You would have to delete the output folder manually. I had submitted a feature/fix request to the MCU ARM project, but that got a low priority, so I doubt it ever will be fixed/improved 😦
  
  LikeLike
  
  Reply ↓
  - Armink on January 13, 2018 at 16:20 said:
    
    Where is your submission, I also go to the feedback.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on January 13, 2018 at 16:50 said:
      
      here we go: https://github.com/gnu-mcu-eclipse/windows-build-tools/issues/3
      
      LikeLike
  - Liviu Ionescu (ilg) on January 28, 2018 at 14:25 said:
    
    A possible workaround is to add a `makefile.targets` file to the project, with a new `clean2` target spliting the remove list over multiple lines, and change the C/C++ Build > Behaviour from `clean` to `clean2`.
    
    More details in one of the comments to https://github.com/gnu-mcu-eclipse/windows-build-tools/issues/3.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on January 28, 2018 at 16:24 said:
      
      Multumesc! I saw that discussion/comments on GitHub, and planned to try it out myself if time permits this evening.
      
      LikeLike