Hi All,
I am seeing an interesting effect due to a specific commit to bitbake/poky,
which is causing the patching of gcc-* recipes from the meta-xilinx layer to
fail.
I understand that master of oe-core has switched to using GCC 4.8.2 since dora,
however no changes to microblaze were added between 4.8.1 and 4.8.2. As such I
have ruled out the patches themselves being the issue. But it appears the
problem is that the patches to the working directory are being done twice
during the intermediate steps of the gcc build.
Build Configuration:
BB_VERSION = "1.21.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "RedHatEnterpriseWorkstation-6.4"
TARGET_SYS = "microblazeel-poky-linux"
MACHINE = "qemumicroblaze"
DISTRO = "poky"
DISTRO_VERSION = "1.5+snapshot-20131128"
TUNE_FEATURES = "microblaze v8.50 little-endian barrel-shift reorder
pattern-compare divide-hard multiply-high fpu-hard"
TARGET_FPU = "fpu-hard"
meta-yocto
meta = "master:82ff33fc398e6574905aa36f618ad06c3c79b8b7"
meta-xilinx = "master:a573551a42e2f4c8efa82db90f938b10e62a3971"
...
ERROR: Command Error: exit status: 1 Output:
Applying patch 0001-Patch-microblaze-Enable-DWARF-exception-handling-sup.patch
patching file gcc/common/config/microblaze/microblaze-common.c
Hunk #1 FAILED at 37.
1 out of 1 hunk FAILED -- rejects in file
gcc/common/config/microblaze/microblaze-common.c
patching file gcc/config/microblaze/microblaze-protos.h
Hunk #1 FAILED at 54.
1 out of 1 hunk FAILED -- rejects in file
gcc/config/microblaze/microblaze-protos.h
patching file gcc/config/microblaze/microblaze.c
Hunk #1 succeeded at 1901 with fuzz 2 (offset 5 lines).
Hunk #2 succeeded at 1940 with fuzz 1 (offset 12 lines).
Hunk #3 succeeded at 2982 with fuzz 2 (offset 31 lines).
Hunk #4 FAILED at 3184.
1 out of 4 hunks FAILED -- rejects in file gcc/config/microblaze/microblaze.c
patching file gcc/config/microblaze/microblaze.h
Hunk #1 succeeded at 199 with fuzz 2 (offset 15 lines).
patching file gcc/config/microblaze/microblaze.md
Hunk #1 FAILED at 2221.
1 out of 1 hunk FAILED -- rejects in file gcc/config/microblaze/microblaze.md
Patch 0001-Patch-microblaze-Enable-DWARF-exception-handling-sup.patch does not
apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in:
/tmp/tmp.AHBPDCkrUT/tmp/work-shared/gcc-4.8.2-r0/temp/log.do_patch.17977
ERROR: Task 750
(/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/libgcc_4.8.bb,
do_patch) failed with exit code '1'
The following other recipes fail at the do_patch step with the exact same error:
ERROR: Task 394
(/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-cross-initial_4.8.bb,
do_patch) failed with exit code '1'
ERROR: Task 474
(/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-cross_4.8.bb,
do_patch) failed with exit code '1'
ERROR: Task 487
(/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-runtime_4.8.bb,
do_patch) failed with exit code '1'
---
I have done some debugging to determine which change caused the effects,
bisecting between the merge base of dora and master (on the poky repo) landed
me on a bitbake commit:
commit 381d5920188398bc53b2454843054c8690bca243
Author: Saul Wold <s...@linux.intel.com>
Date: Thu Nov 21 09:50:41 2013 -0800
bitbake: cooker: add support for using % as a wildcard in bbappend filename
There has been a continuing call for supporting wildcard in bbappend
filenames. The wildcard is actually allow matching of the name and
version up to the point of encountering the %. This approach will
allow for matching of the major or major.minor.
Exampes:
busybox_1.21.1.bb
busybox_1.21.%.bbappend will match
busybox_1.2%.bbappend will also match
if we update to busybox_1.3.0.bb the above won't match, but a busybox_1.%.bb
will.
[YOCTO #5411]
(Bitbake rev: 31bc9af9cd56e7b318924869970e850993fafc5f)
Signed-off-by: Saul Wold <s...@linux.intel.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
Reverting this commit on the top of master results in a functional build. I've
done some 'bitbake -e' scanning with and without the above commit, and I cannot
see any differences between the variables that are changed in the meta-xilinx
.bbappends files. So it does not appear to be a problem in non-inclusion of the
bbappend files, and the ordering of the inclusion appears to be correct as well.
Before I dive any deeper into the bitbake change itself I was hoping someone
might have seen this issue previously or has some insight.
Thanks,
Nathan
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
