Command Line Exceeds Limit

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all. After adding to my project lwip (an example from asf), the compiler began to issue "Command Line Exceeds Limit".

My project and the example of the asf separately compiled without warning.

I don't use directly the command line.

What is this limitation? Limited number of files connected to the project ? Limit the length of file paths?

How to avoid this warning?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found a way to avoid warning: it is necessary to reduce the length of the path to the folder lwip-2.0.2.

Example httpserver works with my project.

There was another problem: lwip conflicts with the function sprintf (stdio.h).

When you output floating point numbers, outputs gibberish.

This occurs after calling the function netif_add.

Has anyone met with such problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The cause of this problem is insufficient of free RAM (11% free RAM).

After optimization of memory problem disappeared (23% free RAM).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just ran into this problem with my rather large project.  I manually updated from lwip-2.0.3 to lwip-2.1.2.  The latest lwip version has more underlying .c files (121 total .c files).  The "Command Line Exceeds Limit" error happens during the linking step.  In my case there are 217 object files to bring in, each file with a modest path length (217 files * modest path length = a really long command line!!).  All together the link command line now exceeds 8192 characters which is a Win10 limit.

 

A quick fix was to reduce the nested folders in my project.  Instead of <project>\lwip\lwip-2.1.2\...\<filename>.c it was reduced to <project>\lwip-2.1.2\...\<filename>.c, reducing the path to 121 files by 5 characters, in turn reducing the linker command line by 5*121=605 characters.  This was enough to temporarily work around the Win10 8192 command line limit problem.

 

A better fix is to change from a single Solution/single Project format in Atmel Studio, to a single Solution/multiple Project format.  I think I'll try building lwip-2.1.2 as it's own project ending in a .a library file, then link it to the original project, old school style :)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got ' warning: Command Line Exceeds Limit' when compiling some of the files in the project, the linker is OK.
Read lots of threads online about this being a Windows 8192 character limitation, because some of the path lengths are pushing the command line over the limit. So I put it to the test and built the project on Ubuntu 20.4. So I get the same error message and the binaries are identical. Now starting to think this is a arm-none-eabi-gcc limit.

 

Bash command line limit is just over 2MiB:

$ getconf ARG_MAX
2097152
$

 

There are suggestions that by going over the limit the compiler behaviour becomes unpredictable, which is less than ideal.

 

  • Does anyone know how critical this warning message is?
  • Do I really need to go through the entire project and refactor all the path lengths with shorter names?

“We are all in the gutter, but some of us are looking at the stars.”
Oscar Wilde

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dfk wrote:
Does anyone know how critical this warning message is?

If it's telling you that the command line is too long, then it will not have got everything that you specified - so it's not going to do what you wanted.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

dfk wrote:
Does anyone know how critical this warning message is?

If it's telling you that the command line is too long, then it will not have got everything that you specified - so it's not going to do what you wanted.

 

I just got this warning after adding a new .h/.c pair to my project.  I subscribe to the philosophy of "any warning is an error", but at the same time, it seems to build and run fine even with this warning.

 

I have the same question as DFK above - Do I really need to go through the entire project and refactor all the path lengths with shorter names?

 

This seems like such a dumb requirement for a modern IDE.  

 

How can I check to make sure that it's using relative instead of absolute paths?  I THINK it's using relative, but if not, I can stomach moving the project out of C:\Users\Name\Documents\Product\Firmware\ProjectName as a quick fix.

 

Alternately, is there a guide to build portions of the project as a library like ScottMN suggested?  I do have some 3rd party libraries in use that are static enough to convert, though I'm not sure how this impacts debugging.  

 

 

Last Edited: Tue. Feb 16, 2021 - 08:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have this exact same question. I am experiencing the same compiler warning when integrating a third party library in my single Atmel Studio project/solution.

 

What is the best approach to solve this?

- Build portions of the project as a library? (If so, how does one do this for Atmel Studio?)

- Keep the third party libraries as separate projects under the same single Atmel Studio solution? (Will this work? Has anyone tried it?).

 

I tried shortening my file paths, but was unable to get them short enough to remove the warning message when integrating a decently large library.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I contacted support about this, and after a little back and forth, the conclusion is that this warning should be safe to ignore, but you should also fix it if you can  ¯\_(ツ)_/¯

 

Transcript below incase I'm misinterpreting something:

 

 

Windows command invocation has a limitation on length of the string being passed. The limitation is 8191 characters for Windows XP or later versions. To avoid this limitation, Atmel Studio creates a file (ld_ar.mk) containing lengthy parameters and passes it for compilation. A warning message (‘Command Line Exceeds Limit’) is given by Atmel Studio to notify the user. At present (Studio build: 7.0.2542), it is not possible to avoid this warning message on Atmel Studio but we do not get this warning by building the project using command line.

----

Thanks for the reply. I have a few additional questions please.

 

  • Is the ld_ar.mk always passed at compilation or just when the 8191 limitation is exceeded?
  • Is the warning simply notifying that the command line would be too long to use IF the ld_ar.mk were not being passed in?
  • Similarly, is this warning safe to ignore since the ld_ar.mk is being used as a workaround?

----

LD is your GNU linker responsible for linking your file and the library. There are multiple instances where is it used, my understanding is that the warning message is generated by a $(warning text…) when the length is exceeded (or when the function is evaluated). Unlike the error function, the make doesn’t exit for a warning. Instead, the text is expanded and the resulting message is displayed, but processing of the makefile continues.

 

"Is the warning simply notifying that the command line would be too long to use IF the ld_ar.mk were not being passed in?"

>> In a way, yes. I think a build tool is being used to help link the files whose PATH exceeds 8191 characters. I'm not quite sure how it is being executed because if we dive deep into the Windows API the actual limit is 32767 characters (Unicode string). Yet the cmd limits it to 8191 characters, so I don't have a definitive answer for this.

 

"Similarly, is this warning safe to ignore since the ld_ar.mk is being used as a workaround?"

>> It should be safe. I would recommend to reduce the name of the folder or decrease the depth of the files if it's possible as a best practice.

 

Last Edited: Mon. Feb 22, 2021 - 12:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Hillridge wrote:
How can I check to make sure that it's using relative instead of absolute paths?

The 'Output' window shows the complete command lines being used - so that's probably a place to start?

 

 

from: https://www.avrfreaks.net/commen...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Follow up:

The "Should be" didn't sit right with me, so I pressed for a firmer answer and got this:

 

It is safe to ignore the message as the line "command line exceeds limit" from the build output is just a build message.

 

It was confirmed that the archiver (arm-none-eabi-ar.exe) is invoked only once and the warning message is posted by just the Atmel Studio IDE. We do not get this warning by building the project using command line.

 

Unfortunately it is not possible to avoid this warning message in the current version of Atmel Studio.

 

However, we can change this warning message into a ‘info message’ or remove it in the future releases.

Looks like I'll just ignore it then.