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
Solved! Go to 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
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
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'
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