Hi,

i use the codesourcery toolchain for a Cortex-M3 for bare-metal
development.
I implemented all the needed syscalls for newlib, and it works as long
as my "syscalls.c" is linked in as object code.
But as i have written a library with common functions and classes for
bootstrapping and starting up with this controller i would like to move
this code there also. When i do that, i get the typical undefined
references.
My link order is
arm-none-eabi-g++ -T"../stm32-128k-20k.ld" {lots of object files}
-o"output.elf" -lstm32-md
No other librarys are getting linked in.

Benjamin Sonnemann wrote:

> No other librarys are getting linked in.

Actually the 'default' libraries are linked in implicitly. The problem
is that your stubs library must be last in the link order (or at least
after libc.a).

Specifying the libraries explicitly in the required order should I think
fix the problem:

-lm -lc -lgcc -lstm32-md

You may find that you need grouping:

--start-group -lm -lc -lgcc -lstm32-md --end-group

or its shorter alternative form:

-( -lm -lc -lgcc -lstm32-md -)

This causes the libraries in the group to be searched iteratively until
no further references are resolved.

You won't need -lm if you are not using the math library, but it won't
hurt (except for a marginal increase in link time perhaps). You may not
need the grouping, but if you do it is generally because you do not have
the correct link-order. Grouping makes link order unimportant, but may
increase link time a little. Grouping is only necessary when the
libraries have circular dependencies, and there is no 'correct' order.


If the above does not work you may have to use -nostdlibs and specify
the library paths explicitly as well as the library link order
(-L<path>). Unfortunately there are several library versions, some are
compiler version specific and/or target specific (newlib contains more
than one library build for various target configurations). Getting the
right paths for your application may not be a straightforward as you
would like. I suggest that you search the installation for libc.a,
libm.a, and libgcc.a to try to figure out which paths you need to
specify for your target, bearing in mind that there are more than one of
each, and libgcc.a is not in the same folder as the other two.

All this is from memory, since I changed jobs I am not currently using
the GNU toolchain, and the project I worked on is not available to me to
check.



Clifford