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