proposal to start merging some source files in libbb/

Bernhard Fischer rep.nop at aon.at
Sat May 20 01:15:00 UTC 2006


Rob,

On Fri, May 19, 2006 at 05:24:44PM -0400, Rob Landley wrote:
>On Thursday 18 May 2006 1:16 pm, Robert P. J. Day wrote:
>>   just before i head for the gym, a repeat of a thought i had a couple
>> months back.  it seems that there's just too many trivial source files
>> in libbb/, and some of them could be merged and be even more
>> meaningful afterwards.
>>
>>   as a trivial example,
>>
>> 	create_icmp_socket.c
>> 	create_icmp6_socket.c
>
>Traditionally the compiler could only include or exclude things at the .o 
>level, so if a .o file had some used functions and some unused functions, it 
>would have to include the whole thing.  The compiler didn't know what was and 
>wasn't used, and the linker couldn't cherry-pick below the object file level.  
>So we broke up the .o functions as small as possible to avoid including 
>unused functions.
>
>We have the ability ability to produce multiple .o files from a single .c 
>file, and we've recently made it easier to use.  More cleanup in that 
>direction is a good thing (followup to svn 15074).
>
>Binutils has also recently developed the ability to do something vaguely sane, 
>with the --gc-sections option circa binutils 2.17 and up.  That's too new to 
>rely on it, but having that be a CHECK_LD option (disabled by 
>DEBUG_PESSIMIZE) would be a good thing, and perhaps we can rely on it and 
>remove our own workarounds for its absence in around 3 years.
>
>>   as another example, how about xgethostbyname*.c?  it's hard to
>> defend a separate source file for a 5-line function, so do the same
>> thing there.
>
>I personally find the most annoying example to be libbb/mtab_file.c.
>
>I'm all for cleaning this up, just be aware of the issues and check the binary 
>size as you go...

You aren't serious about the note about mtab_file, are you?

So why didn't you like this one again? Please explain..

http://www.busybox.net/lists/busybox/2006-March/019965.html



More information about the busybox mailing list