How to reproduce:

1. Create a new program (blink example).
2. Export to gcc ARM
3. Set GCC_BIN variable to point to latest binaries from https://launchpad.net/gcc-arm-embedded
4. type make to compile

The error I get is:

[ash@wrk GccTest_gnu]$ make
/home/ash/arm/gnu_gcc/bin/arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -T./mbed/LPC1768/GCC_ARM/LPC1768.ld -L./mbed/LPC1768/GCC_ARM  -o GccTest.elf main.o mbed/LPC1768/GCC_ARM/cmsis_nvic.o mbed/LPC1768/GCC_ARM/system_LPC17xx.o mbed/LPC1768/GCC_ARM/core_cm3.o mbed/LPC1768/GCC_ARM/startup_LPC17xx.o -lcpp -lcapi  -lstdc++ -lsupc++ -lm -lc -lgcc -lcpp -lcapi  -lstdc++ -lsupc++ -lm -lc -lgcc
/home/ash/arm/gnu_gcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
collect2: error: ld returned 1 exit status
make: *** [GccTest.elf] Error 1
[ash@wrk GccTest_gnu]$ 

This is with 4.7-2012-q4-major from:

https://launchpad.net/gcc-arm-embedded

From what I understand _sbrk is a hook that users of newlib must define on a per-architecture basis?

Am I doing something obviously stupid, or is this a bug?

Ashley

See this page for possible solutions (adding -lnosys)

https://mbed.org/forum/mbed/topic/4226/?page=1#comment-20974

Hi Ashley, Wim, we updated the GCC ARM Embedded exporter:

• Fix the ".s.o" rule for building assembly files adding the "-mcpu=cortex-m3 -mthumb" information.
• Use the new v4.7 "newlib-nano" in the linker rule ("-specs=nano.specs -u _printf_float -u _scanf_float")
• Add missing system library ("-lnosys") in the linker rule

You can use now the new exporter enabling beta mode here: http://mbed.org/betamode/

The fix should appear live around Monday next week.

Cheers, Emilio

Thanks,

While we're on topic, I'd be interested to understand something about the GCC export route:

Would it be possible to link to the ARM embedded libc instead of newlib, whilst still using a GCC toolchain? (or in general any non ARM toolchain)

Ashley

Short answer: No.

Long answer: It could be theoretically possible to hack it, but with mediocre results.

A standard library is designed to go along its compiler.

For example, a good compiler+linker can detect which subset of the printf functionalities have been used (which formats) and it can know which subset of functions need to be linked in from its standard library. GCC ARM Embedded does not know how the printf functionality is split inside the "ARM embedded libc". Similarly, ARMCC does not know how the printf functionality is split inside "newlib".

You would also have to reimplement all the conventions knowledge of the ARMCC linker to decide which system libraries need to be linked in.

Cheers, Emilio

Thanks Emilio,

Presumably you could break all the printf functions into separate object files and link only those required? i.e manually replicating function-sections ?

Actually, turns out that the optimizations done by GCC usually refer to standard library functions:

• GCC printf and other "built-in" optimizations
• gcc/builtins.c

Anyway, there are many subtle problems you could face mixing up standard libraries and compilers. It would be a bad hack.

Cheers, Emilio

Hi,

I still have trouble "make"ing a binary using the GCC ARM export:

$ make

results into:

arm-none-eabi-gcc: error: nano.specs: No such file or directory

This is the case for beta and non-beta version. I also created a new project in the beta version, still same result.

$ arm-none-eabi-gcc version

arm-none-eabi-gcc (GCC) 4.7.3

BR,

@Stefan Vaillant, can you share your makefile or better, the entire project?

Hi,

found the issue:

MacOS ports provides a gcc cross compiling package, which seems not to work:

$ port installed | grep arm
  arm-none-eabi-binutils @2.23.1_2 (active)
  arm-none-eabi-gcc @4.7.3_1 (active)

I installed the version from https://launchpad.net/gcc-arm-embedded/+download, which worked.

BR,