[yocto] Debugging a build issue in an isolated enviroment
Alan Martinovic
alan.martinovic at senic.com
Thu Nov 2 05:51:50 PDT 2017
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 at github.com/getsenic/senic-os-uboot.git;protocol=ssh;branch=${SRCBRANCH};
\
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.p
>>>> atch".
>>>> 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/4897680a/attachment.html>
More information about the yocto
mailing list