[yocto] Debugging a build issue in an isolated enviroment

Burton, Ross ross.burton at intel.com
Thu Nov 2 04:50:36 PDT 2017


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/368cc226/attachment.html>


More information about the yocto mailing list