GNU Arm Embedded Toolchain

Can not compile (link) because of the famous undefined '_sbrk'

Asked by Murat Ursavas

I tried to update my compiler from Freddie Chopin's Bleeding Edge Toolkit to official ARM-GCC 4.7 2013 Update 2 but could not create the final image because of the well known "sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'" error.

It wasn't there with the old compiler. I know this is related to libnosys.a library and it should be added to linker parameters. Here is my parameter group:

"-lc -lnosys --specs=nano.specs"

I'm sure ld.exe (linker) is accessing the libnosys.a via using Sysinternals' Procmon. It reads the library well without an error.

So shouldn't I get the final elf file? Am I missing something else?

P.S: I'm using calloc/free, that's why it asks for _sbrk function.

Toolchain:
-------------
IDE: Eclipse Juno 4.2.2 (+ OpenOCD 0.7.0 and Zylin-Cygwin)
Compiler: ARM-GCC 4.7-2013-q2-update
MCU: STM32L100RB
Debugger: STLink/V2 (STM32L Discovery Kit)

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Thomas Grieger
Solved:
Last query:
Last reply:
Revision history for this message
Best Thomas Grieger (t-grieger) said : 		#1

Hi Murat,

the _sbrk function is located in the syscalls.c of the newlib library. Either you add the syscalls.c from the library to your source code or you could try to add it via the "redboot-syscalls.specs" file.

Best regards,
Thomas

Revision history for this message
Murat Ursavas (murat-ursavas) said : 		#2

Hi Thomas,

Thanks for your recommendation. At first I tried your second solution and tried to add "--specs=redboot.specs" to the linker options. Compilation gone mad and said "It can not fit in your flash".

Then I downloaded the source code of actual release and found the "newlib-nano-1.0/libc/sys/arm/syscalls.c". Added it to my code but it failed. "Swi.h" file was missing, added it also and voila it compiled fine (with a lot of silly warnings. I don't know why someone writes this code,

int
_getpid (int n)
{
  return 1;
  n = n;
}

as it will create warnings obviously.

So, right now I'm able to compile but couldn't understand exactly what happened. I had a smaller syscalls.c file but it was excluded from the build, so the linker shouldn't be finding the _sbrk because of that. Then what was the source for it?

Also, binary releases of this compiler are multi-lib and includes many arm architectures. Why don't we have this functions in "libc_s.a" library? It is already architecture dependent.

Revision history for this message
Murat Ursavas (murat-ursavas) said : 		#3

Thanks Thomas Grieger, that solved my question.