On 1/24/20 3:19 PM, Khem Raj wrote: > 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 >
I am not sure I follow what you want to see changed. Do you want the to try and fix up the problem where the variables are initially set? Example: classes/kernel-arch.bbclass:KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}" I see there are some BSPs that append to KERNEL_LD, so this problem could happen at a later point. The other possibility is adding an echo to force the trimming without using the python. @@ -41,8 +38,8 @@ module_do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ KERNEL_VERSION=${KERNEL_VERSION} \ - CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ - AR="${KERNEL_AR}" \ + CC="$(echo ${KERNEL_CC})" LD="$(echo ${KERNEL_LD})" \ + AR="$(echo ${KERNEL_AR})" \ O=${STAGING_KERNEL_BUILDDIR} \ KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \ ${MAKE_TARGETS} @@ -52,7 +49,7 @@ module_do_install() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake DEPMOD=echo MODLIB="${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}" \ INSTALL_FW_PATH="${D}${nonarch_base_libdir}/firmware" \ - CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ + CC="$(echo ${KERNEL_CC})" LD="$(echo ${KERNEL_LD})" \ O=${STAGING_KERNEL_BUILDDIR} \ ${MODULES_INSTALL_TARGET} -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core