KDS 3.0 Linker Line Length Issue

[bcamp]

Hi

In KDS 3.0, there seems to be a bug:

1) Put in your source files with nice long paths

2) Put in lots of source files

3) Hit the Windows 8192 character limit on the command line (like with a 9K line)

Now the line that starts with :

arm-none-eabi-g++ -mcpu=cortex-m0plus ...

needs to be extended by putting in a ^ character when passed to Windows. The code appears to be smart enough to do this. The problem is that

the linker spits back an error:

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

There is no "/Generated_Coe/" directory. It should be "/Generated_Code/". The ^ appears to be overwriting the d in the word Code. Looking at the string before it goes to Windows, there is no spelling error there. You can get the dropped character to move around by changing the lengths of your file names. You can also get it to work by putting dummy .o files in the /Generated_Code/ directory if only the file name is mangled.

I suppose the work around for now is to not use stupid long paths and file names ...

So much fun!

Bob

[BlackNight · Accepted solution]

Hi Bob,

this is a known issue on Windows, see the release notes (first item in Known Issues and Workarounds).

The simple solution is described there and here: Solving the 8192 Character Command Line Limit on Windows | MCU on Eclipse

I appologize for the issue, and I hope the above solution helps you.

Erich

PS: I know, not everyone reads the release notes. I rarely read it myself too ;-).

[bcamp]

Hi

Thanks for the information on re-doing the tool chain. I'd sort of hoped that gutting a three day old release would not be needed. I suppose

that switching to a nice new Mac would also be a solution. I'll put in a ticket with IT and see how well that all works out :smileyhappy:

Will future updates of KDS use the tools you mentioned? My concern is an update that comes out next week and things get subtly broken

in some other way. I would prefer to keep the tool chains on all of the machines and platforms as "vanilla" as possible.

--------------------

Looking at the release note proposed solution:

Most of the linker line length is "fed" by the MQX / PEX / SDK file references. The linker line is mostly paths like the one in:

./SDK/rtos/mqx/mqx_stdlib/source/stdio/fflush.o

If I simply put in enough drivers and MQX stuff with zero user code, I hit the same wall. I don't see how I can control the length of the paths

that PEX / MQX comes up with. Changing the ./SDK/rtos/mqx/mqx/mqx_stdlib/source/ to something like ./OSsrc/ would be a real

solution with the existing tools.  The other one to change would be  ./SDK/platform/drivers/src/ to ./PTdrv/ .

So - Is there an easy way to put in a few more links and get rid of the long(er) paths?

Yes, the "other" answer is - don't use PEX. Let's keep it a Processor Expert setup for now.

--------------------

Far more interesting is the fact that the existing tools *do* understand the command line limit and make an effort to get around it.

They understand that a ^ in the line will do a continue and solve the problem. In practice the output is not truncated. The entire string (almost)

gets passed to the linker. The problem is that they overwrite one character in the string when they put in the ^ rather than extending the length of the

string.

You can fairly easily see this going on by looking at the Eclipse side error the linker feeds back " ..... No such file .." and by cutting and pasting the proposed

command line from Eclipse onto a Windows command prompt. The error messages are quite different.

The Eclipse error message contains an "almost correct" file name. You can also create a dummy .o file in the appropriate directory and get the

existing Eclipse tools to do a build. Since the name of the file changes each time the line is re-mangled, this is not a long term solution.

Because it's a relatively simple programming error, it *seems* like a correctable issue with the existing chain ...

Bob

[BlackNight]

Yes, this issue did exist on Windows for a very long time, and up until these new Liviu binaries were available, the usual answer in the forums was 'use Linux instead'. Unfortunately it was too late for the v3.0.0 release to have these tools from Liviu rolled in. I expect that a next release of KDS will have these tools included. I have used these updated/fixed tools on my side for several weeks and have not seen any issues.

To me the real solution is to use the tools mentioned in that post. Reducing the path length is always a good thing, but painful ini most cases.

I hope this helps,

Erich

[bcamp]

Hi

Ok, I'll give the new make tools a try. It will take a while since Source Forge is blocked on our corporate network. As long as that is what will be in any future updates it's a valid solution. Guess I get to take the rest of the day off :smileyhappy:

Bob

[BlackNight]

Hi Bob,

in case this helps you: attached is the download from

https://sourceforge.net/projects/gnuarmeclipse/files/Build%20Tools/gnuarmeclipse-build-tools-win32-2...

Erich

[bcamp]

Hi

Well so much for taking the rest of the day off :smileyhappy:

The files install fine and they do fix the problem. In KDS 3.0 they are all in the <SDK>\bin\ folder so it's actually easier to do the update than it was in KDS 2.0 (one less click ...).

Thanks! (I'll try not to talk so much in your classes from now on).

Bob