Re: linux-next: build failure after merge of the arm64 tree

[Will Deacon]

Hello Masahiro,

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)
> 
> Maybe,
> 
> def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "OBJCOPY=$(OBJCOPY)"
> $(srctree)/scripts/tools-support-relr.sh)
> 
> 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.

Will

--->8