command line too long linker problem - still exist in KDS 3.1?

[mike1974]

There was a problem in KDS 2.0 with linker command lines being too long (actually a Windows command line limit).  But I was wondering if KDS 3.1 has solved this problem?

Or, do I still have to use the "makefile.defs" solution, as described here:

https://community.freescale.com/thread/334455

[BlackNight]

Hi Michael,

KDS 3.1 only updates the Eclipse (plugins) part, but does not touch the outside files like the <kds>\bin folder.

So the bin folder remains the same with that update.

But you don't have to use the 'makefile.defs' solution: there is an easier way with Solving the 8192 Character Command Line Limit on Windows | MCU on Eclipse

I hope this helps,

Erich

[mike1974]

Thank you Erich, I tried that solution last year with KDS 2.0, but couldn't get it to work.  I posted some questions on your website (mcuoneclipse), but it was never solved.  So, I'm a little hesitant to try it again now.

For now, can I keep the "makefile.defs" solution?  It seems to build fine with that. 

The only problem I have now is this:

'Invoking: Cross ARM C++ Linker'

arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -T "C:/Users/Mike/workspace.kds/A9950V0002/Project_Settings/Linker_Files/ProcessorExpert.ld" -Xlinker --gc-sections -L"C:/Users/Mike/workspace.kds/A9950V0002/Project_Settings/Linker_Files" -L"C:\Users\Mike\workspace.kds\emWin_V528b\Debug" -Wl,-Map,"A9950V0002_dbg.map" --specs=nano.specs -o "A9950V0002_dbg.elf" @ObjectList

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-sbrkr.o): In function `_sbrk_r':

sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-signalr.o): In function `_kill_r':

signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-signalr.o): In function `_getpid_r':

signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-writer.o): In function `_write_r':

writer.c:(.text._write_r+0x10): undefined reference to `_write'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-closer.o): In function `_close_r':

closer.c:(.text._close_r+0xc): undefined reference to `_close'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-fstatr.o): In function `_fstat_r':

fstatr.c:(.text._fstat_r+0xe): undefined reference to `_fstat'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-isattyr.o): In function `_isatty_r':

isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-lseekr.o): In function `_lseek_r':

lseekr.c:(.text._lseek_r+0x10): undefined reference to `_lseek'

c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg_s.a(lib_a-readr.o): In function `_read_r':

readr.c:(.text._read_r+0x10): undefined reference to `_read'

[BlackNight · Accepted solution]

Hi Michael,

sure, if something works for you, there is no reason to change things.

>>but couldn't get it to work.

Not sure, as this does not ring a bell?

About your linker errors: it seems you are want to linke file I/O to it (semihosting)? If not, add

--specs=nosys.specs

to the linker file commands to use dummy system functions.

I hope this helps,

Erich