Re: [PATCH] kbuild: work around distcc/icecc madness

[Ingo Molnar]

* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

> On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > 
> > * Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > 
> > > On Fri, 20 Mar 2009, Ingo Molnar wrote:
> > > > > ---
> > > > >  scripts/Kbuild.include |    5 +++--
> > > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > Doesnt fully work:
> > > > 
> > > > arch/x86/kernel/entry_32.S:346: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > arch/x86/kernel/entry_32.S:394: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > arch/x86/kernel/entry_32.S:519: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > arch/x86/kernel/entry_32.S:614: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > arch/x86/kernel/entry_32.S:685: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > arch/x86/kernel/entry_32.S:754: Error: unknown pseudo-op: `.cfi_signal_frame'
> > > > 
> > > > config attached. Distcc driven build.
> > > 
> > > Same config works fine here. Do you have different 
> > > compilers/binutils on your distcc cluster ? I tripped over this 
> > > distcc feature in the past, that's why I have switched to iceccc.
> > 
> > the distcc binutils is different from the host build environment 
> > binutils and compiler. This always worked fine - can we preserve 
> > it?
> 
> It depends what you define as "worked fine".

as in "did not fail the build" :-)

> The point is that the CFI checks are done at compile time by 
> checking binutils. If you have two versions - one with and one 
> without CFI support - then it's just a question of luck which one 
> is checked. So in your case it might have worked because both 
> distcc and your local gcc agreed that CFI is not enabled, but the 
> reason why the distcc check for CFI fails is because it fails to 
> handle the stdin input and not because it does not support CFI.
> 
> So with my patch distcc gives you the correct answer, but now you 
> trip over the local binutils lack of CFI support.
> 
> I don't think that such a setup is something we need to preserve.

i dont do anything weird. i use:

CROSS_COMPILE='distcc 
/opt/crosstool/gcc-4.2.2-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-'

host compiler was never supposed to be the same in terms of 
capability as target compiler.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/