On Fri, Jan 24, 2020 at 1:05 PM Jason Wessel <jason.wes...@windriver.com> wrote:
>
> On 1/24/20 1:13 PM, Khem Raj wrote:
> > On 1/24/20 10:19 AM, Christopher Larson wrote:
> >> What makefile change caused this? That behavior doesn't make much sense
> >> given how make processes its command-line arguments.
> >>
> >
> > I agree with you here, it could be a rare check where one want to define
> > what collect progam should be used ( ld or ar )
> >
> > besides, recently we moved AR to be gcc-ar/llvm-ar by default in config
> > metadata, which is not going to work out of box for compiling kernel and
> > modules, so overriding it with KERNEL_AR in
> > module_do_compile/install/configure tasks is good change.
>
> I am not actually sure which part of kbuild is parsing the LD
> arguments. My best guess is that it is actually all the nested
> gnumake filter calls causing the issue.
>
> With some further experimentation I determined that a space at the end
> of the LD= is what causes it to think the next argument is part of the
> prior one. The poky distro is defining KERNEL_LD as:
>
> % bitbake vboxguestdrivers -e |grep ^KERNEL_LD
> KERNEL_LD="x86_64-poky-linux-ld.bfd "
>
> The kbuild really doesn't like that space at the end. You can trash out
> a host native kernel compile module build by adding the arguments:
> LD="ld " JUNK_VAR="junk"
>
> Attempting to debug/fix kbuild doesn't seem like the right answer.
>
> The next version of this patch looks like what is below. Would that be ok?
>
>
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index c0dfa35061..7b0a85a06d 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -12,6 +12,9 @@ python __anonymous () {
> if dep.startswith("kernel-module-"):
> extra_symbols.append("${STAGING_INCDIR}/" + dep +
> "/Module.symvers")
> d.setVar('KBUILD_EXTRA_SYMBOLS', " ".join(extra_symbols))
> + d.setVar('KERNEL_CC', d.getVar('KERNEL_CC').rstrip())
> + d.setVar('KERNEL_LD', d.getVar('KERNEL_LD').rstrip())
> + d.setVar('KERNEL_AR', d.getVar('KERNEL_AR').rstrip())
> }
>
no one else uses KERNEL_* vars, so if modules cant use it then we have
an issue, perhaps just delete it in base class where KERNEL_* vars are set
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
