cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sgilbertson
Observer
Observer
9,069 Views
Registered: ‎01-05-2012

SDK: Is there a fix for linker command line over 8192 characters?

Jump to solution

My SDK (Zynq) project has been getting bigger and bigger, and I suddenly started getting a strange linker error:

ld.exe: unrecognized option '--start-grup'

It's strange because my linker command line does not include "--start-grup", but it does include "--start-group".

 

The command line that fails (split into separate lines for clarity) is:

arm-none-eabi-g++ -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard 
-Wl,-build-id=none -specs=Xilinx.spec -Wl,-Map -Wl,"zmeter1_app.map" 
-Wl,-T -Wl,../src/lscript.ld 
-L../../freertos823_xilinx_bsp_0/ps7_cortexa9_0/lib -o "zmeter1_app.elf" 
( ... a whole lot of object files ... )
./src/main.o 
-Wl,--start-group,-lxil,-lfreertos,-lgcc,-lc,-lstdc++,--end-group 
-Wl,--start-group,-lxil,-llwip4,-lgcc,-lc,--end-group

By "a whole lot" I mean enough that the overall command length is 8248 bytes.

 

According to https://support.microsoft.com/en-ca/kb/830473:

On computers running Microsoft Windows XP or later, the maximum length of the string that you can use at the command prompt is 8191 characters.

And make.exe invokes cmd.exe, so that limit applies during builds.

 

I found a blog post describing the problem, and suggesting that a specially-modified toolchain can avoid the problem by not using cmd.exe. The blog post points out that the error messages you get can be strange when the problem arises. I'm hesitant to go messing with the toolchain in the Xilinx SDK, though.

 

Does anybody know of a way to circumvent the 8192-byte limit, without resorting to splitting my application project up into separate library projects, or is that the only way to make it link?

 

0 Kudos
1 Solution

Accepted Solutions
stephenm
Xilinx Employee
Xilinx Employee
11,778 Views
Registered: ‎09-12-2007
This is a limitation on the windows OS and will be seen in the gui and batch mode.

The a WA,asa previous poster mentioned is to create a static library from groups of your .o files.
awb://www.adp-gmbh.ch/cpp/gcc/create_lib.html

Add these to the linker compile. If you where doing this for a lot of projects you would need to script this to make it more user friendly

View solution in original post

0 Kudos
16 Replies
balkris
Xilinx Employee
Xilinx Employee
9,033 Views
Registered: ‎08-01-2008
you can try running SDK in batch mode
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_3/SDK_Doc/concepts/sdk_c_batch_mode.htm

check this ARs

http://www.xilinx.com/support/answers/35619.html

you can try with this tool
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug1208-xsct-reference-guide.pdf

Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
sgilbertson
Observer
Observer
9,020 Views
Registered: ‎01-05-2012

That was definitely worth a try, but it does not affect the error.

 

On a positive note, though, I found that the thing builds just fine on my home PC, just not on the office PC. Both are running Vivado WebPack 2016.2, and both are 64-bit Windows 10 that had been upgraded from Windows 7 Pro 64-bit. I will be investigating to see what's different. Maybe Microsoft has only recently increased the limit, and maybe I have that hotfix/update only on my home PC. I'll post here when I figure it out.

 

Anyhow, details...

 

I did:

  • Xilinx Software Commandline Tool (XSCT) v2016.2
  • setws (an empty directory)
  • importprojects (path to my SDK working directory)

It copies all the source over to the fresh working directory and builds the projects. All projects built OK, including the one with the super-long linker command line. It seems to just run make, though, so I wondered why it works in the command line tool but not in Eclipse. Are they using a different make.exe, I wondered?

 

Then I did a build in the SDK, and it worked! Checked the length of the linker command: 8331 bytes. This is on my home PC, but the earlier error was on my office PC.  Remote accessing the office computer, and running the same batch commands there, I get the same error as before.

 

So the difference is something to do with the two PCs, not with batch vs. Eclipse.

 

I looked at AR# 35619, and I'm wondering if that's really the one you meant. It talks about overflowing the defined memory spaces, which is not a problem in my case.

 

I also looked at the PDF you linked, which provides lots of good information about batch mode. Thanks.

 

0 Kudos
sgilbertson
Observer
Observer
9,016 Views
Registered: ‎01-05-2012

Noticing that the command-line length was just a bit different in the home vs. office build (8248 vs. 8331 characters, I grabbed the latest code from version control on the office PC. Now the two command lines exactly match (8331 bytes), and it now builds on both PCs.

 

So the problem doesn't appear to be that the command line exceeded 8191 characters, but rather an issue with the specific command line.

 

Comparing the two, the only differences are two object files present with the latest code and not with the older code:

  • ./src/settingLists/ConfigureNumericSettings.o
  • ./src/menus/SoftwarePlaygroundMenu.o

The linker command lines are otherwise 100% identical. All the defines, paths and options are identical, for example.

 

Acting on a hunch, I looked at that old command line, specifically around character #8192, and found "--end-group". Character #8192 is the "o" in "group" (but not in a place that would make "--start-grup", as in the error message). So the problem isn't literally that the build software has a hiccup right at character 8192, but it begins to look like that sort of bug. In the new (longer) command line, character 8192 is in the middle of one of the object-file names, and yet that object file links just fine.

 

Back to work as normal now, but I'll be watching for the problem to resurface.

 

0 Kudos
sgilbertson
Observer
Observer
8,936 Views
Registered: ‎01-05-2012

I have further characterized the bug.

 

I added a few more classes, and the problem's there again:

 

arm-none-eabi-g++: error: ./src/MeterApplicaion.o: No such file or directory

Again, the same error appears when I to a batch build. The command line is now 8371 bytes long:

 

 

... ./src/MeterApplication.o ...

The "t" in "MeterApplication" (i.e. the character g++ missed) is in column 8209.

 

 

An earlier command line (8247 bytes long) had this error:

 

ld.exe: unrecognized option '--start-grup'

The command line was:

 

... -Wl,--start-group ...

So "ld" had missed the "o" in "group", which lies at column 8209.

 

A command that did not get an error was 8330 characters long:

 

... ./src/main.o   -Wl,--start-group ...

The character at column position 8209 is the first space after "main.o". Since there are several spaces in a row, losing one of those did not cause a build error.

 

 

So here's a description of the bug: When building, the character at position 8209 in the command line is discarded. Unless you get lucky (like it being one of a chain of spaces), that causes a build error.

 

It's definitely a bug in the 2016.2 build tools (I haven't tried other versions).

 

 

 

 

0 Kudos
maltehoenselaar
Visitor
Visitor
8,023 Views
Registered: ‎12-15-2016

I have the same Bug even at character 8192. It's the same error with SDK 2016.1 and 2016.3.

Does anyone have a solution for this Problem?

 

0 Kudos
ahdavidcook
Visitor
Visitor
7,864 Views
Registered: ‎01-18-2017

I believe I have the same problem. Tried 2016.2 and 2016.4. Any solutions yet?

0 Kudos
ahdavidcook
Visitor
Visitor
7,853 Views
Registered: ‎01-18-2017
I've got round this problem for now by splitting off some modules into a static library. I *will* hit this problem again :(
0 Kudos
maltehoenselaar
Visitor
Visitor
7,833 Views
Registered: ‎12-15-2016

I try it in a Linux VM Ubuntu 14.04 and there it's working without any problems. So this problem only happened under Windows. Unfortunately for me it isn't a solution. Is there any solution from Xilinx for this problem? Please help...

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
11,779 Views
Registered: ‎09-12-2007
This is a limitation on the windows OS and will be seen in the gui and batch mode.

The a WA,asa previous poster mentioned is to create a static library from groups of your .o files.
awb://www.adp-gmbh.ch/cpp/gcc/create_lib.html

Add these to the linker compile. If you where doing this for a lot of projects you would need to script this to make it more user friendly

View solution in original post

0 Kudos
sgilbertson
Observer
Observer
5,514 Views
Registered: ‎01-05-2012

@stephenm wrote:
This is a limitation on the windows OS and will be seen in the gui and batch mode.

Strictly speaking it's not a limitation of Windows. It's a limitation of CMD.EXE.

https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation

 

The maximum command length for Windows (i.e. passed to CreateProcess function) is 32,768 characters according to Microsoft.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

 

Using a different shell would bump the limit to 32768. I haven't tried it but there is an Eclipse plugin which claims to do that:

https://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/

Perhaps there's also a way to configure Eclipse to use a different EXE for the shell without a plugin. Again I haven't tried it.

 

The best solution, I think, would be for the SDK to allow a mode in which it writes the list of object files to a text file, then passes that text file in an "@" parameter when linking, rather than listing all the object files in the command line.


@stephenm wrote:
The a WA,asa previous poster mentioned is to create a static library from groups of your .o files.
awb://www.adp-gmbh.ch/cpp/gcc/create_lib.html

Is there an easy way in the SDK to create a library project?

 

Last time I looked I couldn't find that.

 

 

0 Kudos
ahdavidcook
Visitor
Visitor
5,298 Views
Registered: ‎01-18-2017

Is there any news regarding a better resolution for this? I've just hit the limit for a second time on this project, and this time I'm having to pull out a set of modules that are much more interwoven with the rest of the project.

0 Kudos
ahdavidcook
Visitor
Visitor
5,289 Views
Registered: ‎01-18-2017
Update: I don't think I can do this, as I don't think I can let static libraries refer to each other. I'm now looking for an entirely different solution.
0 Kudos
ahdavidcook
Visitor
Visitor
4,574 Views
Registered: ‎01-18-2017

Update: I have used the solution as sgilbertson mentioned by creating my own makefile based upon the automatically generated one, but replacing the linker line:

 

	-$(RM) obj
	mkdir -p obj
	for SUBDIR in $(SUBDIRS); do \
		echo $$SUBDIR ; \
		cp $$SUBDIR/*.o obj ; \
	done;
	arm-none-eabi-ar -r  "output.a" obj/*.o $(USER_OBJS) $(LIBS)

 

This uses wildcards to build the project. However, the SUBDIR includes need to be manually synced from the automatically generated makefile. Not ideal, but works.

0 Kudos
ahdavidcook
Visitor
Visitor
3,947 Views
Registered: ‎01-18-2017

Hit another limit at 32768 characters. Updated the makefile to link from a file listing all objects:

 

	-$(RM) obj
	mkdir -p obj
	for SUBDIR in $(SUBDIRS); do \
		cp $$SUBDIR/*.o obj ; \
	done;
	
	ls -1 obj/*.o > objects.txt
	
	arm-none-eabi-ar -r  "output.a" @objects.txt $(USER_OBJS) $(LIBS)
0 Kudos
kenkrz
Observer
Observer
2,688 Views
Registered: ‎03-18-2015

I'm having the same problem with 17.4 - 

0 Kudos
MKHen
Observer
Observer
1,144 Views
Registered: ‎09-18-2020

Maybe try the following:

  • Separate files to build an archive from project.
  • Clear all call to the archiver in the GUI
  • Insert a post-buil step to call the archiver like: mb-gcc-ar rsc "libfoo.a" ./foo/*.o ./foo/foosub/*.o
0 Kudos