I could be wrong, but I thought if you had a library with a
hundred .o files, and you only accessed symbols from one .o
file, ld only pulled in the one .o file.  This is (IIRC) one of the
advantages of making a whole bunch of little .o files in your libraries, as
NetBSD does -- strcmp() is in a separate object file from gettimeofday(), etc.

  So one thing that could be done is to make sure that there is
only a single symbol in every .o file.  But that can be a source-code
maintenance nightmare even moreso than the current libc setup.  :)

  Brian Grayson

On Tue, Oct 19, 2004 at 09:42:43AM -0400, Brian Rose wrote:
> But I think what Ian is looking for is a way to strip out all the unused 
> portions of a library. For example the library 'widget' is composed of two 
> exported routines, 'foo' and 'bar'. 'Program1' uses only the 'foo' 
> function, but when linked, the code for 'bar' is included in the final 
> image.
> 
> While it may be possible to create a tool that extracts the code from a 
> library and creates a new custom library, I think the better approach is to 
> have a script that builds a custom C library from the libc source, based on 
> the requirements of the program.
> 
> I have not looked into this, but another possible solution would be if the 
> linker could notice that a particular object file was not used and discard 
> it. That way, you could simply link against all the .o files used to build 
> libc and the linker would toss out the ones that were not needed.
> 
> Sorry I can't offer any real solutions. But the time to develop this would 
> be considerable, and for my applications, several hundred kilobytes was 
> just not worth it. Maybe the next time I get laid off, I'll look at it. ;-).