----- Original Message -----
From: <d_yerrick@...>
> John Seghers wrote:
> > For example (and it may be a bad example, I don't know if these
> > are packaged together) if malloc, calloc, free, and realloc are
> > all packaged together, you will have all four of them linked
> > even if you only use malloc/free.
>
> >From what I've seen in malloc() implementations, malloc() and
> free() are the big complicated functions, and calloc() and
> realloc() are tiny wrappers around malloc(). For instance,
> calloc() is merely a malloc() followed by a memset(), and
> realloc() is malloc(), memcpy(), free().

My point was not about how much those specific functions impacted
the final product. My point was more about granularity in general.
Function-level linkers handle this on a function-by-function basis
whether the code is in a library or not

This becomes even more important with template libraries, since by
definition the template class must be in the compilation unit where it
is used. If you have 10 functions (each of similar complexity) to provide
the implementation of the template, and your code uses the template
to instantiate a class, but only uses 2 of those functions, you're stuck
with code for all 10 being compiled.

A linker that includes everything from a compilation unit in the final
product will include all of this dead code. A linker that performs
function-level linking will strip it out.

The specific answer came that newlib is pretty granular--generally
one function per file--which is good. The GCC tool chain developers,
however, (whenever I've seen this issue debated) have basically said
that if you want function-level linking, you have to do it manually--and
they
see this as an acceptable process. Basically use #ifdefs to break a single
source file into individual compilation units, one for each function. I
find
that to be an unacceptable amount of manual labor considering that
other tool chains have had this feature for 8-10 years.

- John