# Solving the 8192 Character Command Line Limit on Windows

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:

1. Use short directory names
2. Use short file names
3. Reduce the command line length with using relative paths instead of absolute file paths
4. 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 on http://gnuarmeclipse.github.io/blog/2015/02/28/plugins-v2.6.1-201502281154-released/ 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:

1. make.exe is in <kds_2.0.0>\toolchain\bin
2. 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 (see his site on http://gnuarmeclipse.livius.net/) 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”

• 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.

Like

• 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.

Like

• 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

Like

• I don’t know how KDS manages the PATH, apparently it should work, but it looks like we are missing something. 😦

Like

1. 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.

Like

• 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.

Like

• Yes, but if using the Eclipse build system, this would have to be generated by the plugins, which is not the case.

Like

• 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’… 😦

Like

• Good catch, thanks, fixed now 🙂

Like

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

Like

3. 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.

Like

4. 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

Like

• 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.

Like

• 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?

Bye,
Steven

Like

• 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?

Like

• 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

Like

• 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 Like • 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. Like • Eric, Thanks for your help with this, I will followup with the bug report if I have anything more to add. Thanks again! Like • No worries, both works for me 🙂 Like 5. There are about 900 files in my project, so seems I have broken past some other barrier? Like • Did you install the build tools using the setup? Can you confirm that make.exe and sh.exe are in a folder named bin? Like • 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? Like • unless AR has some limitations, there should be no differences, make.exe uses sh.exe to run a child process. Like • 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?

Like

• 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).

Like

• 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

Like

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

Thanks!

Like

7. 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!

Like

• thanks for confirmation. Yes, this should be usable for any Windows Eclipse based gcc tools, including KDS v1.x, v2.x and V3.x

Like

• 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**.

Like

8. 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 ?

Like

• Can you check your PATH if really it is using the updated GNU ARM Eclipse binaries?

Like

• 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?

Like

9. 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.

Like

• 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.

Like

10. 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??

Like

• Hi Yaran,
I have not seen this with Windows 7 and 64bit. Same problem if you use the 32bit version of the tools?

Like

• is the compiler crashing or the make? What if you use a DOS shell to run the make/rm/etc?

Like

11. 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 😦

Like

• 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).

Like

• 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.)

Like

• Ok, understood, that’s a very good reason to keep things frozen.

Like

• Comes from years of (bad) experience. 😉

Like

• 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.

Like

12. 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

Like

• Yes, it seems that with the most recent release more files are necessary, thanks for pointing this out.

Like

• 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.

Like

• 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. 🙂

Like

• 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!

Like

13. 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.

Like

• 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.

Like

14. 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?

Like

• > 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).

Like

• 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?

Like

• > 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.

Like

• good idea!

Like

• 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.

Like

15. 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?

Like

• 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.

Like

• 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 😦

Like

This site uses Akismet to reduce spam. Learn how your comment data is processed.