[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090320193334.GA19501@elte.hu>
Date: Fri, 20 Mar 2009 20:33:34 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Sam Ravnborg <sam@...nborg.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] kbuild: work around distcc/icecc madness
* Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 20 Mar 2009, Ingo Molnar wrote:
> >
> > * Thomas Gleixner <tglx@...utronix.de> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists