Subject: Re: Shrinking NetBSD - deep final distribution re-linker
To: None <tech-embed@NetBSD.org (rfc822 Compliance issue To>
From: Brian Rose <lists@brianrose.net>
List: tech-embed
Date: 10/19/2004 09:42:43
Jared Momose wrote:

>> Sorry for quite confusing subject, just i don't know how exactly 
>> express my
>> ideas :) Not sure where exactly should i post this message..
> 
> 
> tech-embed is definitely the place for this type of discussion.
> 
> it sounds like you are describing crunchgen. man crunchgen, and take a 
> look at src/distrib/i386/floppies/ramdisk-big/list for an example. 
> crunchgen does have limitations and caveats (which i can enumerate upon 
> request) but all can be worked around in one way or another. and there 
> is an advantage of sharing all common code pages w/o ld glue. :^)
> 
> best regards,
> jared.

Does crunchgen remove unused portions of the code, though? I thought it 
simply linked all the programs into one file. In which case all of libc's 
extra baggage would come along with it.

<aside>BTW - I have written an article on using crunchgen to make some 
minimal NetBSD systems...

http://www.bsdnewsletter.com/2003/09/Features102.html
</aside>

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. ;-).

--

Brian