Re: linux-next: build failure after merge of the arm64 tree
From: Will Deacon
Date: Wed Aug 07 2019 - 11:25:14 EST
On Wed, Aug 07, 2019 at 11:43:02PM +0900, Masahiro Yamada wrote:
> On Wed, Aug 7, 2019 at 8:46 PM Will Deacon <will@xxxxxxxxxx> wrote:
> > On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrote:
> > > We're setting NM to something else based on a config option, which I
> > > presume sets up some sort of circular dependency that confuses
> > > Kconfig. Removing this fragment of the makefile (or appending
> > > --synthetic unconditionally) also makes the problem go away.
> Exactly. This makes a circular dependency.
> Kconfig determines the environment variable 'NM' has been changed,
> and re-runs.
> > Yes, I think you're right. The lack of something like KBUILD_NMFLAGS means
> > that architectures are forced to override NM entirely if they want to pass
> > any specific options. Making that conditional on a Kconfig option appears
> > to send the entire thing recursive.
> Adding KBUILD_NMFLAGS is probably the right thing to do.
> (Is there somebody who wants to volunteer for this?)
I don't think so ;) We don't do this for many other tools, and there's only
this one case that really seems to require it.
> But, for this particular case, I vote for
> the entire removal of --synthetic.
> This dates back to 2004, and the commit message
> did not clearly explain why it was needed.
> The PowerPC maintainers should re-evaluate
> whether or not this flag is necessary.
> ppc32 is working without --synthetic,
> so probably ppc64 would be ...
Again, this is up to the PPC maintainers.
> > diff --git a/init/Kconfig b/init/Kconfig
> > index d96127ebc44e..a38027a06b79 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -31,7 +31,7 @@ config CC_HAS_ASM_GOTO
> > def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
> > config TOOLS_SUPPORT_RELR
> > - def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
> > + def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(CROSS_COMPILE)nm" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
> > config CC_HAS_WARN_MAYBE_UNINITIALIZED
> > def_bool $(cc-option,-Wmaybe-uninitialized)
> def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "OBJCOPY=$(OBJCOPY)"
> will work.
Oh yes, I prefer that. I've included the updated patch below, and I'll
put it into -next shortly so that we resolve the build breakage. Hopefully
we'll have a better fix once the ozlabs folks wake up.
> Or more simply
> def_bool $(success,$(srctree)/scripts/tools-support-relr.sh)
> CC, LD, OBJCOPY, NM are environment variables,
> so I think tools-support-relr.sh can directly use them.
Maybe, but the other scripts invoked here tend to pass $(CC) through as
an argument, and that helps with your observation below...:
> However, this bypasses the detection of environment variable changes.
> If a user passes NM= from the command line, Kconfig will no longer
> notice the change of NM.
... but since my proposal also breaks this, then I think your idea of just
dropping $NM for now is best.