[yocto] Debugging a build issue in an isolated enviroment
Alan Martinovic
alan.martinovic at senic.com
Thu Nov 2 06:31:59 PDT 2017
Found what I was asking for with:
bitbake -e <package>
going through the output, there are mentions of patch_do_patch().
I've traced it to meta/classes/patch.bbclass.
However, trying to execute just the patching for the recipe doesn't work.
build⟫ bitbake -c patch u-boot-fw-utils-senic
...
ERROR: Task do_patch does not exist for target u-boot-fw-utils-senic
(/home/alan/senic-os-update/oe/../meta-senic/recipes-bsp/u-boot/u-boot-fw-utils-senic_2017.03.bb:do_patch).
Close matches:
do_fetch
do_unpack
ERROR: Command execution failed: 1
On Thu, Nov 2, 2017 at 1:51 PM, Alan Martinovic <alan.martinovic at senic.com>
wrote:
> That I can't see the changes for that particular patch in the source (by
> manually checking the source for the changes).
> Other patches are applied correctly, I can trace them in the sources.
>
> I have no "temp/log.do_patch" and find notions of patches (both the
> successfully and unsuccessfully applied ones) only in the log.do_fetch and
> log.do_unpack steps.
>
> Is there a way to grep through how a recipe looks like when all the
> inherited parts have been expanded?
> There seems to be a do_patch task (http://www.yoctoproject.org/
> docs/2.3/ref-manual/ref-manual.html#patching-dev-environment)
> which I would grep for in that expanded recipe.
>
> For more insight, the current recipe (the one I'd like to see expanded)
> looks like this:
>
> $ cat u-boot-fw-utils-senic_2017.03.bb
> SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities"
> LICENSE = "GPLv2+"
> LIC_FILES_CHKSUM = "file://Licenses/README;md5=
> a2c678cfd4a4d97135585cad908541c6"
> SECTION = "bootloader"
> DEPENDS = "mtd-utils"
>
> require recipes-bsp/u-boot/u-boot-fw-utils-mender.inc
>
> SRCBRANCH = "senic/v2017.03"
> SRC_URI = "git://git@github.com/getsenic/senic-os-uboot.git;
> protocol=ssh;branch=${SRCBRANCH}
> <http://git@github.com/getsenic/senic-os-uboot.git;protocol=ssh;branch=$%7BSRCBRANCH%7D>;
> \
> file://boot.cmd \
> file://0001-sun8i-configs-Add-CONFIG_BOOTCOUNT_LIMIT-ENV-for-men.patch
> \
> file://0002-sunxi-common-Remove-variables-used-by-Mender.patch
> \
> file://default-gcc.patch"
>
> SRC_URI_remove = "file://0003-Integration-of-Mender-boot-code-into-U-Boot.
> patch"
> SRC_URI_append = " file://0001-Integration-of-
> Mender-boot-code-into-U-Boot.patch"
>
> SRCREV = "5233f173335a61b1e2b9120c55422a8d60ff7ffe"
> PV = "v2017.03+git${SRCPV}"
> S = "${WORKDIR}/git"
>
> # For Mender.io integration
> BOOTENV_SIZE = "0x20000"
> PROVIDES += "u-boot-fw-utils"
> RPROVIDES_${PN} += "u-boot-fw-utils"
>
> INSANE_SKIP_${PN} = "already-stripped"
> EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}
> ${CFLAGS} ${LDFLAGS}" V=1'
> EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS}
> ${LDFLAGS}" V=1'
>
> inherit uboot-config
>
> do_compile () {
> oe_runmake ${UBOOT_MACHINE}
> oe_runmake env
> }
>
> do_install () {
> install -d ${D}${base_sbindir}
> install -d ${D}${sysconfdir}
> install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_
> printenv
> install -m 755 ${S}/tools/env/fw_printenv
> ${D}${base_sbindir}/fw_setenv
> install -m 0644 ${S}/tools/env/fw_env.config
> ${D}${sysconfdir}/fw_env.config
> }
>
> do_install_class-cross () {
> install -d ${D}${bindir_cross}
> install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_
> printenv
> install -m 755 ${S}/tools/env/fw_printenv
> ${D}${bindir_cross}/fw_setenv
> }
>
> SYSROOT_DIRS_append_class-cross = " ${bindir_cross}"
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> BBCLASSEXTEND = "cross"
>
>
>
>
> On Thu, Nov 2, 2017 at 12:50 PM, Burton, Ross <ross.burton at intel.com>
> wrote:
>
>> What do you mean by patches not being applied correctly?
>> temp/log.do_patch has the output from patch so that might show that you've
>> a patch that applies with lots of fuzz and is applied incorrectly.
>>
>> Ross
>>
>> On 2 November 2017 at 11:46, Alan Martinovic <alan.martinovic at senic.com>
>> wrote:
>>
>>> I see, so I can't use the devshell to debug why the patch hasn't been
>>> correctly applied.
>>>
>>> The answer you gave help for debugging actual build and configure
>>> problems.
>>> Debugging patching seems to be out scope for this thread.
>>> Will start a new one.
>>>
>>>
>>> On Thu, Nov 2, 2017 at 12:13 PM, Burton, Ross <ross.burton at intel.com>
>>> wrote:
>>>
>>>> The patching is done by a bbclass (patch.bbclass) and helper modules
>>>> (meta/oe/lib/patch.py), so you can't execute it like a shell task (such as
>>>> do_compile).
>>>>
>>>> Ross
>>>>
>>>> On 2 November 2017 at 11:05, Alan Martinovic <alan.martinovic at senic.com
>>>> > wrote:
>>>>
>>>>> Thanks for the suggestions
>>>>> Am currently implementing both of them and am trying to understand how
>>>>> the patching is done.
>>>>>
>>>>> In the temp directory I can see all the tasks.
>>>>> For some reasons the patch wasn't applied correctly and I'm debugging
>>>>> why.
>>>>>
>>>>> I have patches from before which are being correctly applied, one of
>>>>> them being "0001-sun8i-configs-Add-CONFIG
>>>>> _BOOTCOUNT_LIMIT-ENV-for-men.patch".
>>>>> Am using that one just as a reference for this example.
>>>>> I want to see the steps done to apply the patch so I do:
>>>>>
>>>>> temp$ grep -r 0001-sun8i-configs *
>>>>> temp$ grep -r quilt *
>>>>>
>>>>> I am expecting to see some commands related to the patching process in
>>>>> one of the run scripts.
>>>>> For example, "quilt" followed by some arguments or
>>>>> "0001-sun8i-configs-Add-CONFIG_BOOTCOUNT_LIMIT-ENV-for-men.patch"
>>>>> being applied
>>>>> by some other tool instead of quilt.
>>>>>
>>>>> I only end up with some findings in the log files (log.do_fetch,
>>>>> log.do_unpack which don't tell me much).
>>>>>
>>>>>
>>>>> Where are the steps that apply the patches located?
>>>>>
>>>>> Be Well :)
>>>>> Alan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I've gotten to the
>>>>>
>>>>> On Wed, Nov 1, 2017 at 8:05 PM, Alex Kiernan <
>>>>> alex.kiernan at hivehome.com> wrote:
>>>>>
>>>>>> On 1 November 2017 at 17:38, Alan Martinovic <
>>>>>> alan.martinovic at senic.com> wrote:
>>>>>>
>>>>>>> I'm just upgrading to pyro and have some issues with u-boot-fw-utils.
>>>>>>>
>>>>>>> The error fails at do_compile stage which looks like this:
>>>>>>>
>>>>>>> do_compile () {
>>>>>>> oe_runmake ${UBOOT_MACHINE}
>>>>>>> oe_runmake env
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> The error is:
>>>>>>>
>>>>>>> Log data follows:
>>>>>>> | DEBUG: Executing shell function do_compile
>>>>>>> | NOTE: make -j 16 CROSS_COMPILE=arm-senic-linux-gnueabi-
>>>>>>> CC=arm-senic-linux-gnueabi- gcc -march=armv7ve
>>>>>>> -mfpu=neon-vfpv4
>>>>>>> -mfloat-abi=hard -mcpu=cortex-a7
>>>>>>> --sysroot=/home/alan/senic-os-update/build/tmp-glibc/work/se
>>>>>>> nic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017
>>>>>>> .03+gitAUTOINC+5233f17333-r0/recipe-sysroot
>>>>>>> -O2 -pipe -g -feliminate-unused-debug-types
>>>>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib
>>>>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se
>>>>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0=/usr/src/debug/u-boot-
>>>>>>> fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0
>>>>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib
>>>>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se
>>>>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot-native=
>>>>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib
>>>>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se
>>>>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot=
>>>>>>> -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed V=1
>>>>>>> | ERROR: oe_runmake failed
>>>>>>> | make -f ./Makefile silentoldconfig
>>>>>>> | make -f ./scripts/Makefile.build obj=scripts/basic
>>>>>>> | cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
>>>>>>> -fomit-frame-pointer -o scripts/basic/fixdep
>>>>>>> scripts/basic/fixdep.c
>>>>>>> | /bin/sh: 1: cc: not found
>>>>>>>
>>>>>>>
>>>>>>> I would assume this is a to specific error to ask help about. It
>>>>>>> seems
>>>>>>> that the compiler isn't being called correctly (it's called as cc,
>>>>>>> which isn't the full compiler name).
>>>>>>> Suggestions are welcome but that isn't the reason for my post.
>>>>>>>
>>>>>>>
>>>>>> Guessing... apply this in your recipe:
>>>>>>
>>>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/rec
>>>>>> ipes-bsp/u-boot/files/default-gcc.patch?h=pyro
>>>>>>
>>>>>> --
>>>>>> Alex Kiernan
>>>>>> Senior Engineering Manager
>>>>>>
>>>>>> hivehome.com <http://www.hivehome.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hive | London | Cambridge | Houston | Toronto
>>>>>> The information contained in or attached to this email is
>>>>>> confidential and intended only for the use of the individual(s) to which it
>>>>>> is addressed. It may contain information which is confidential and/or
>>>>>> covered by legal professional or other privilege. The views expressed in
>>>>>> this email are not necessarily the views of Centrica plc, and the company,
>>>>>> its directors, officers or employees make no representation or accept any
>>>>>> liability for their accuracy or completeness unless expressly stated to the
>>>>>> contrary.
>>>>>> Centrica Connected Home Limited (company no: 5782908), registered in
>>>>>> England and Wales with its registered office at Millstream, Maidenhead
>>>>>> Road, Windsor, Berkshire SL4 5GD.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171102/4082427b/attachment.html>
More information about the yocto
mailing list