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

[Thomas Gleixner]

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".

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.

Thanks,

	tglx
--
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/