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.
>
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137367):
https://lists.openembedded.org/g/openembedded-core/message/137367
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]]
-=-=-=-=-=-=-=-=-=-=-=-
