tech-embed archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Shrinking NetBSD - deep final distribution re-linker
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. ;-).
Home |
Main Index |
Thread Index |
Old Index