On Tue, Apr 21, 2020 at 10:39 PM Bruce Ashfield via lists.openembedded.org <[email protected]> wrote: > > On Tue, Apr 21, 2020 at 9:32 PM Dan Callaghan > <[email protected]> wrote: > > > > Excerpts from Bruce Ashfield's message of 2020-04-21 08:33:34 -04:00: > > > On Tue, Apr 21, 2020 at 5:37 AM Dan Callaghan > > > <[email protected]> wrote: > > > > > > > > We need to copy include/config/auto.conf into ${STAGING_KERNEL_BUILDDIR} > > > > to avoid module compilation errors like this: > > > > > > > > | make[1]: Entering directory > > > > 'build/tmp-glibc/work-shared/machine/kernel-source' > > > > | make[2]: Entering directory > > > > 'build/tmp-glibc/work-shared/machine/kernel-build-artifacts' > > > > | > > > > | ERROR: Kernel configuration is invalid. > > > > | include/generated/autoconf.h or include/config/auto.conf > > > > are missing. > > > > | Run 'make oldconfig && make prepare' on kernel src to > > > > fix it. > > > > | > > > > | make[2]: *** > > > > [build/tmp-glibc/work-shared/machine/kernel-source/Makefile:641: > > > > include/config/auto.conf] Error 1 > > > > > > > > We also need scripts/basic/fixdep to avoid errors like this: > > > > > > > > | make[1]: Entering directory > > > > 'build/tmp-glibc/work-shared/machine/kernel-source' > > > > | make[2]: Entering directory > > > > 'build/tmp-glibc/work-shared/machine/kernel-build-artifacts' > > > > | CC [M] > > > > build/tmp-glibc/work/vendor-linux/tehuti-module/0.3.6-r0/git/TLK10232_phy_Linux.o > > > > | /bin/sh: scripts/basic/fixdep: No such file or directory > > > > | make[3]: *** > > > > [build/tmp-glibc/work-shared/machine/kernel-source/scripts/Makefile.build:303: > > > > > > > > build/tmp-glibc/work/vendor-linux/tehuti-module/0.3.6-r0/git/TLK10232_phy_Linux.o] > > > > Error 127 > > > > > > > > And scripts/mod/modpost to avoid errors like this: > > > > > > > > | Building modules, stage 2. > > > > | MODPOST 1 modules > > > > | /bin/sh: scripts/mod/modpost: No such file or directory > > > > | make[3]: *** > > > > [build/tmp-glibc/work-shared/machine/kernel-source/scripts/Makefile.modpost:92: > > > > __modpost] Error 127 > > > > > > > > Most of the time, the absence of these files is masked by the > > > > make-mod-scripts recipe's do_configure task, which causes a whole bunch > > > > of extra files to be built into ${STAGING_KERNEL_BUILDDIR} (including > > > > these two). Typically make-mod-scripts will be built before any kernel > > > > modules, and so it didn't matter that do_shared_workdir was missing > > > > these files. > > > > > > > > > > The design is that, make-mod-scripts is what provides those files, we > > > don't want to copy them, since it is an ever incomplete list (more so > > > in the past, but the concept still holds). > > > > Okay, I think you're saying that what do_shared_workdir claims to do > > (populate ${STAGING_KERNEL_BUILDDIR} with whatever files are needed to > > build kernel modules) should actually be handled by make-mod-scripts > > instead. > > > > Does that mean, do_shared_workdir has no purpose? Or is it doing > > something else I don't realise? > > How would what populates it change the purpose of what it does ? > Just like our SDK and on target module support, those files are generated > by the kernel build itself, not copied. > > shared-workdir was created to stop slinging around the sheer number of > files in a kernel build, it was causing us severe build performance issues. > > Having the smallest possible list of explicitly copied files is the goal. > The lists are fragile, and inevitably need constant tweaking. Witness > the messing around with kernel-devsrc that I have to do, and the only > reason that is tolerated is to make the minimal possible development > components. > > > > > > > However the problem will be evident if you do certain sequences of > > > > tasks, for example a complete build first (so that make-mod-scripts is > > > > already built), then: > > > > > > > > bitbake linux-yocto my-kernel-module -c clean > > > > bitbake my-kernel-module -c install > > > > > > Why can't we fix the dependency ? We chased a few of these around when > > > the mod-scripts recipe was introduced, and this just looks like a > > > variant we missed. > > > > Right, so there *is* already a correct dependency on > > make-mod-scripts:do_compile. The problem is, in the scenario I gave > > above, that task is already done and Bitbake is not going to run it > > again. But in fact, the stuff it left behind in > > ${STAGING_KERNEL_BUILDDIR} was cleaned out when I cleaned the > > linux-yocto recipe. > > Yes, and that clean is supposed to invalidate things, and trigger the > re-run.
Hi Dan, Are you seeing this on master, or some other branch ? I can run the following on master, as often as I like: % bitbake linux-yocto hello-mod -c clean; bitbake hello-mod -c install And I see the required scripts coming and going from the build artifacts as expected: build [/home/bruc...-artifacts]> find . -name 'fixdep' ./tools/objtool/fixdep ./scripts/basic/fixdep # after the clean: build [/home/bruc...-artifacts]> find . -name 'fixdep' # after the install build [/home/bruc...-artifacts]> cd .. build [/home/bruc...qemux86-64]> cd - /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-build-artifacts build [/home/bruc...-artifacts]> find . -name 'fixdep' ./tools/objtool/fixdep ./scripts/basic/fixdep Is there something different with your module recipe than the one in meta-skeleton ? Can you share it, so I can debug further ? Bruce > > > > > I guess the real issue is that we have this "shared" work directory > > which a bunch of different recipes contribute files to, but can be > > cleaned out by running the "clean" task on any one of several different > > recipes. > > We've solved that issue in the past, I'll have a look on Wednesday to > see what may have changed and (re)broken it. There may be a bugzilla > floating around for that, I'll see if I can track it down as well. > > Bruce > > > > > -- > > Dan Callaghan <[email protected]> > > Software Engineer > > Opengear <https://opengear.com/> > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137392): https://lists.openembedded.org/g/openembedded-core/message/137392 Mute This Topic: https://lists.openembedded.org/mt/73168943/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
