Yeah, I broke find. Unfortunately, the easy fix is gcc >= 3.4.

[Rob Landley]

Okay, this is a problem that's likely to crop up again, and I'd like to figure 
out the best way to fix it.

After switching all of find's CONFIG_ entries to ENABLE_ entries, I ran make 
allyesconfig and make allnoconfig, but that didn't catch the case with find 
enabled but none of its sub-features enabled.  (Which breaks.)

The problem is, there are #ifdefs around the declarations of the static 
variables that these features use.  One of the advantages of using the ENABLE 
stuff is that all the code is compiled and syntaxed checked in each 
configuration, which is generally good because it catches what would 
otherwise be configuration dependent build breaks.  The _down_ side is that 
chopping out chunks of code with #ifdef and optimizing them out with 
if(ENABLE) doesn't mix well.

The reason for these #ifdefs around variables is the same reason there are 
#ifdefs around some static functions: gcc 3.3 and earlier is too stupid to 
figure out they're not used and optimize them out.   A new compile option, 
"-funit-at-a-time", was introduced in gcc 3.4, aimed at exactly this problem: 
finding unreachable static functions and variables.  Once we start using 
that, the #ifdefs around these things can go away.

So today, this leaves me uncertain quite how to proceed.  The easy way to 
handle this is to remove the #ifdefs around static variables and function 
names when switching over from CONFIG to ENABLE, which means that both gcc <= 
3.3 and gcc >= 3.4 will compile something that runs, but the older compiler 
will miss some obvious optimizations.

Probably the best hybrid approach is to remove the #ifdefs around variables 
(which causes the hard-to-fix build breaks under ENABLE, don't take up too 
much run-time memory even when the compiler misses them, and don't 
necessarily increase the size of the resulting binary if they're initialized 
to 0), but leave the #ifdefs around functions (which take up noticeably more 
space) until gcc 3.3 and earlier drop out of common usage.

Opinions?  Anyone want to estimate how long it'll take gcc 3.3 and earlier to 
drop out of common usage?  (I'm guessing that 3.4 will become 50% of the 
installed base in a year or so, but won't drop below 20% usage for another 3 
or 4 years.  If 3.4 or 4.0 does produce significantly better code, we should 
have a note to that effect in the README.  Has anybody done comparisons?)

Rob

P.S.  Note I'm talking about busybox 1.1.  The 1.0 line should happily 
continue to use gcc 3.3 and earlier as optimally as possible.