Newlib-lpc ar/ld weirdness and workaround
Started by ●May 1, 2005
I noticed the example makefiles that come with Aeolus Development's
newlib-lpc port build elf binaries for the tests by passing all the
library's .o files to arm-elf-ld. I thought this was strange, so I
changed it to instead link against libnewlib-lpc.a built from these
same files ... but it doesn't work! The elf file is bigger, the .hex
file is smaller and test2 doesn't output anything to the serial port.
After trying a few things, I noticed that if you build one .o file
from all the library C sources and another .o file from the library
assembler sources and then build these into libnewlib-lpc.a, it works
again.
I still don't understand why it doesn't work if you build the library
with one .o file for each source file. I tried a number of different
variations checking that I was using the same versions of the files
and they were specified in the same order. I'm using GNUARM and
targeting an Olimex LPC-H2294 board.
Brian
Reply by ●May 1, 20052005-05-01
At 08:05 PM 5/1/05 +0000, deunhido wrote:
>I noticed the example makefiles that come with Aeolus Development's
>newlib-lpc port build elf binaries for the tests by passing all the
>library's .o files to arm-elf-ld. I thought this was strange, so I
>changed it to instead link against libnewlib-lpc.a built from these
>same files ... but it doesn't work! The elf file is bigger, the .hex
>file is smaller and test2 doesn't output anything to the serial port.
>
>After trying a few things, I noticed that if you build one .o file
>from all the library C sources and another .o file from the library
>assembler sources and then build these into libnewlib-lpc.a, it works
>again.
>
>I still don't understand why it doesn't work if you build the library
>with one .o file for each source file. I tried a number of different
>variations checking that I was using the same versions of the files
>and they were specified in the same order. I'm using GNUARM and
>targeting an Olimex LPC-H2294 board.
I think I can shed some light on this.
The basic problem is that the newlib library you are linking against
already has the routines that the newlib-lpc support is providing. When
you link them together with your source the routines in newlib get picked
up in preference over the ones in newlib-lpc. Since these stubs will be
designed for some other board they don't work very well if at all.
When you place all of the C in one module then a reference to a routine not
in newlib will bring in all the stubs as well and therefore none of the
original newlib stubs will get linked in.
The 'proper' solution is to either remove the stubs from the newlib archive
you are using (use ar and remember to backup the original first) or to
rebuild newlib without the stubs in the first place.
I just added a quick note to the documentation for this. I hope to expand
on it for release 5, which is in the works.
Robert
You know, somehow it never occurred to me until people started mentioning
it that anyone would build newlib with a random set of stubs. I had
thought it would be built either with no stubs for a general use library or
with specific documented stubs if targeted at a particular micro/board. " 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>I noticed the example makefiles that come with Aeolus Development's
>newlib-lpc port build elf binaries for the tests by passing all the
>library's .o files to arm-elf-ld. I thought this was strange, so I
>changed it to instead link against libnewlib-lpc.a built from these
>same files ... but it doesn't work! The elf file is bigger, the .hex
>file is smaller and test2 doesn't output anything to the serial port.
>
>After trying a few things, I noticed that if you build one .o file
>from all the library C sources and another .o file from the library
>assembler sources and then build these into libnewlib-lpc.a, it works
>again.
>
>I still don't understand why it doesn't work if you build the library
>with one .o file for each source file. I tried a number of different
>variations checking that I was using the same versions of the files
>and they were specified in the same order. I'm using GNUARM and
>targeting an Olimex LPC-H2294 board.
I think I can shed some light on this.
The basic problem is that the newlib library you are linking against
already has the routines that the newlib-lpc support is providing. When
you link them together with your source the routines in newlib get picked
up in preference over the ones in newlib-lpc. Since these stubs will be
designed for some other board they don't work very well if at all.
When you place all of the C in one module then a reference to a routine not
in newlib will bring in all the stubs as well and therefore none of the
original newlib stubs will get linked in.
The 'proper' solution is to either remove the stubs from the newlib archive
you are using (use ar and remember to backup the original first) or to
rebuild newlib without the stubs in the first place.
I just added a quick note to the documentation for this. I hope to expand
on it for release 5, which is in the works.
Robert
You know, somehow it never occurred to me until people started mentioning
it that anyone would build newlib with a random set of stubs. I had
thought it would be built either with no stubs for a general use library or
with specific documented stubs if targeted at a particular micro/board. " 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
