New tools build, now get conflicting symbol defns.

Jeff Johnston
Thu Dec 13 17:01:00 GMT 2007

Rick Mann wrote:
> Hi. I've been building for an XScale target for some time now using 
> binutils-2.18, gcc-4.2.1, and newlib-1.15.
> I built the tools as "arm-elf", and I pass -mcpu=xscale to the builds, 
> but in general it worked. Now I've gone and built a new toolsuite using 
> binutils-2.17, gcc-4.2.1, and newlib-1.15. This time, it was a combined 
> (single tree) build. It seemed to go okay, and a minor change to my 
> Makefile (to change arm-elf to xscale-elf) seems to allow everything to 
> compile.
> But then I run into some link errors.
> Before, I provided a certain amount of glue to my build. I defined the 
> following symbols in a file "glue.c":
> _sbrk()
> _exit()
> _getpid()
> _kill()
> isatty()
> _read()
> _write()
> _lseek()
> _close()
> _fstat()
> My implementations of this all worked fine, allowing me to send bytes 
> back and forth to the target board.
> Now, when I build with the newly-built tools, I get a lot of multiple 
> definitions warnings for those symbols above (listed  below). libc.a and 
> syscalls.c in newlib seem to have defined them for me, and I'm not sure 
> how to get them to not be defined. I could allow multiple defs, but then 
> I have to make sure my versions are used. I forgot something about 
> "standalone" builds, not sure if there's a different option I should be 
> using.
> Could someone please suggest a fix for this issue? I'd really just like 
> to keep my own defs. I use C++ and C, as well as asm code. I have my own 
> linker script. Thank you very much.

You want to configure with --disable-newlib-supplied-syscalls

-- Jeff J.

More information about the Newlib mailing list