Archive (library) which overrides syscalls from toolchain's archive?

[Nick Clifton]

Hi Freddie,

> If I want to link with my syscalls archived I get the following error:

> libg.a(lib_a-sbrkr.o): In function `_sbrk_r':
> newlib/newlib/libc/reent/sbrkr.c: 58: undefined reference to `_sbrk'

> The problem is that my own _sbrk_r() from the archive is discarded and the
> function from libg.a is used (a stub for _sbrk()).

This sounds like a linker command line ordering problem.  [Aside: It 
would really help if you posted your linker command line ...]

What is probably happening is that your archive is being placed on the 
linker command line *before* the object file that calls _sbrk_r.  So at 
the time that your archive is scanned, there are no undefined references 
to _sbrk_r.  So it is discarded.  Later on on the command line something 
else does call _sbrk_r, so an unresolved reference is created.  Then 
later on still libg.a appears on the command line, this is scanned and 
it provides a definition of _sbrk_r.  Hence the version in libg.a is 
pulled in.  Unfortunately this version wants to call _sbrk, but no 
further libraries left on the command line provide that function, so the 
linker generates the error message above.


> Is there any (possibly simple and generic) way to solve it?

Probably.  Reordering your linker command line ought to work.

> or forcing _sbrk_r() to be initially undefined with
> EXTERN(_sbrk_r) in the linker script, but this didn't change much.

Did you try using --undefined=_sbrk_r on the linker command line ?


> Basically I'm looking for a way to just force some functions to be taken from
> designated archive.

Have you tried using the --wrap linker command line option ?  You could 
wrap calls to _sbrk_r and then provide the wrapped version in your own 
archive.

Cheers
   Nick

PS. There is also the --whole-archive linker command line option, which 
could be used to force all of your archive to be included in the link, 
but it is probably overkill.