08-18-2016 02:42 PM
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?
01-29-2017 12:24 PM
08-18-2016 08:39 PM
08-19-2016 07:40 AM
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.
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.
08-19-2016 08:02 AM
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:
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.
08-24-2016 11:04 AM
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).
12-15-2016 11:37 PM
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?
01-20-2017 02:57 AM
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...
01-29-2017 12:24 PM
01-29-2017 12:53 PM
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.
The maximum command length for Windows (i.e. passed to CreateProcess function) is 32,768 characters according to Microsoft.
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:
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.
The a WA,asa previous poster mentioned is to create a static library from groups of your .o files.
Is there an easy way in the SDK to create a library project?
Last time I looked I couldn't find that.
03-23-2017 03:24 AM
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.
03-23-2017 05:15 AM
09-28-2017 05:21 AM
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.
04-27-2018 02:37 AM
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)
11-17-2020 03:58 AM
Maybe try the following: