Re: 2.6.25-rc2-mm1 (x64 thermal build failure)

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 20 Feb 2008 08:21:33 +0100 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Le Tue, 19 Feb 2008 15:21:29 -0800,
> Andrew Morton <akpm@linux-foundation.org> a __crit :
> 
> > ug, sorry, if I'd realised it was like this I'd have said "don't
> > bother". Apart from the obvious problem, this means that people will
> > keep breaking CONFIG_DMI=n all the time, because they will forget the
> > ifdefs, and the number of people who test with CONFIG_DMI=n will be
> > small.
> 
> Yes, #ifdef CONFIG_DMI is not very comfortable. That why I proposed
> things such as DECLARE_DMI_FIXUP_TABLE(), because it would force people
> to use these macros, which would then be working correctly depending on
> DMI=y/n. However, there's still the issue of driver_data that I
> mentionned in my earlier post.
> 
> What should I do ? Option 1 ? Option 2 ? Give up with the patch ?
> 
> Thanks for your comments,

Option 1 would be best, I think:

 1) Remove the #ifdef CONFIG_DMI around DMI fixup tables and callbacks
    definition, so that everything exists and gcc is happy. gcc is able
    to optimize out the DMI fixup table (it is not present in the binary
    when compiling with DMI=n), but gcc doesn't seem to be able to
    optimize out the DMI fixup callbacks (they are still present in the
    binary). So this would leave some unused code in the binary, which
    is not completely satisfying.

gcc _should_ be able to remove the callbacks as long as they are static and
have no references.  If even the latest gcc versions are still incluing the
unreferenced, static function in the final vmlinux then let's get gcc fixed?