WARNING: Host distribution "arch-rolling" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Parsing recipes: 100% |######################################################################################################################################################################################################| Time: 00:00:16
Parsing of 906 .bb files complete (0 cached, 906 parsed). 1235 targets, 45 skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION = "1.19.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "arch-rolling"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "poky"
DISTRO_VERSION = "1.4+snapshot-20130816"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU = "vfp-neon"
CSL_VER_MAIN = "2009q1-203"
EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
meta-sourcery = "master:a7ee19cd79448c0a5f492a1244054f9999411522"
meta
meta-yocto
meta-yocto-bsp
meta-networking = "master:2db46232785f53067eb289d8da12cd4bf5eb4ea2"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: BUILDSPEC (log file is located at /home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_package_write_rpm.16054)
ERROR: Logfile of failure stored in: /home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_package_write_rpm.16054
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing python function do_package_write_rpm
| DEBUG: Executing python function read_subpackage_metadata
| DEBUG: Python function read_subpackage_metadata finished
| DEBUG: Executing python function do_package_rpm
| DEBUG: Executing python function write_specfile
| NOTE: Not creating empty RPM package for linux-libc-headers
| NOTE: Not creating empty RPM package for linux-libc-headers-dev
| NOTE: Creating RPM package for gdbserver
| NOTE: Not creating empty RPM package for gdbserver-dbg
| NOTE: Creating RPM package for libstdc++6
| NOTE: Creating RPM package for libstdc++-dev
| NOTE: Creating RPM package for libstdc++-staticdev
| NOTE: Not creating empty RPM package for libquadmath
| NOTE: Not creating empty RPM package for libquadmath-dev
| NOTE: Not creating empty RPM package for libquadmath-staticdev
| NOTE: Not creating empty RPM package for libgomp
| NOTE: Not creating empty RPM package for libgomp-dev
| NOTE: Not creating empty RPM package for libgomp-staticdev
| NOTE: Creating RPM package for libgcc-s1
| NOTE: Creating RPM package for libgcc-s-dev
| NOTE: Creating EMPTY RPM Package for libc6-dbg
| NOTE: Creating RPM package for catchsegv
| NOTE: Creating RPM package for sln
| NOTE: Creating RPM package for nscd
| NOTE: Creating RPM package for ldd
| NOTE: Creating RPM package for eglibc-utils
| NOTE: Creating RPM package for libthread-db1
| NOTE: Not creating empty RPM package for eglibc-pic
| NOTE: Creating RPM package for libcidn1
| NOTE: Creating RPM package for libmemusage
| NOTE: Creating RPM package for libsegfault
| NOTE: Creating RPM package for eglibc-pcprofile
| NOTE: Not creating empty RPM package for libsotruss
| NOTE: Creating RPM package for libc6
| NOTE: Creating RPM package for eglibc-extra-nss
| NOTE: Creating RPM package for libc6-dev
| NOTE: Creating RPM package for eglibc-staticdev
| NOTE: Creating RPM package for eglibc-doc
| DEBUG: Python function write_specfile finished
| DEBUG: Executing shell function BUILDSPEC
| error: line 29: invalid tag value("^[A-Za-z0-9+._]+$") Version: Version: UNKNOWN(Execution of '/usr/local/arm+2009q1/bin/arm+none+linux+gnueabi+gdb +v' failed with exit code 127:
| error: Package has no %description: gdbserver.armv7a_vfp_neon
| Building target platforms: armv7a_vfp_neon-poky-linux-gnueabi
| DEBUG: Python function do_package_rpm finished
| DEBUG: Python function do_package_write_rpm finished
| ERROR: Function failed: BUILDSPEC (log file is located at /home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_package_write_rpm.16054)
ERROR: Task 80 (/home/lpapp/Projects/poky/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_package_write_rpm) failed with exit code '1'
NOTE: Tasks Summary: Attempted 388 tasks of which 384 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
/home/lpapp/Projects/poky/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_package_write_rpm
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

See the following bugreport for details: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4921

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4988

Please apply the change, or let me know if there is any other way to solve the issue.

Note, opening an issue for meta-external-toolchain against this repo, as suggested by layer's README.md.

systemd-boot_%.bbappend from meta-external-toolchain is not compatible with ccache class:
-EFI_CC_tcmode-external = "${@'${CC}'.split()[0]} ${EFI_TUNE_ARCH}" assignment will extract ccache from ${CC} instead of extracting correct compiler.

Suggested change:

diff --git a/core/recipes-bsp/systemd-boot/systemd-boot_%.bbappend b/core/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index dbeb9c39f6fc..966a09e561db 100644
--- a/core/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/core/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -3,5 +3,5 @@
 # external toolchain.
 EFI_TUNE_ARCH = "-m32"
 EFI_TUNE_ARCH_x86-64 = "-m64"
-EFI_CC_tcmode-external = "${@'${CC}'.split()[0]} ${EFI_TUNE_ARCH}"
+EFI_CC_tcmode-external = "${CCACHE}${HOST_PREFIX}gcc ${EFI_TUNE_ARCH}"

Please see https://bugzilla.yoctoproject.org/show_bug.cgi?id=4921 for the discussion, the comments are too long and with false leads to copy/paste here in full. Comment 15 is the most relevant:

Interesting data point: installed the pro version of the 2013.05 toolchain to /usr in a
fresh chroot, set EXTERNAL_TOOLCHAIN = "/usr", and successfully built most of a
core-image-minimal, so got past this error.

It seems that it's either specific to the lite toolchain (testing that next), or it's not seen
with ubuntu and I'll have to fire up an arch chroot.

Hello:
--CPU：Intel ATOM 32bit
--Yocto：poky-dylan-9.0.3
--toolchain：ia32-2012.09-62-i686-pc-linux-gnu-i386-linux

Modify
--Modify MACHINE = "qemux86" in conf/local.conf
--Add EXTERNAL_TOOLCHAIN = "path/to/ia32-2012.09_install" in conf/local.conf
--Add the meta-sourcery layer to my BBLAYERS in conf/bblayers.conf
When executing bitbake core-image-minimal -c populate_sdk,it will issue:
/path/to/ia32--2012.09/i686-pc-linux-gnu/bin/ld：cannot find crti.o：No such file or directory
/path/to/ia32--2012.09/i686-pc-linux-gnu/bin/ld：cannot find -lc
/path/to/ia32--2012.09/i686-pc-linux-gnu/bin/ld：cannot find crtn.o：No such file or directory

1.Does poky-dylan-9.0.3 support to make SDK with external toolchain of meta-sourcery?
2.if first problem say yes ,according to 4.2. Cross-Development Toolchain Generation of mega-manual.html, why the task of do_compile gcc-cross-canadian will be failed?

                                                                                                                   Thank you!

I am working on support the Android NDK/VNDK building environment for OE. Then the android ndk would work as an external toolchain here.
I don't know what I should define in the script for the EXTERNAL_TOOLCHAIN_SETUP_SCRIPT, I can't find the document for it.

(Forwarding the meta-sourcery part from https://bugzilla.yoctoproject.org/show_bug.cgi?id=4932)

The arm 2009q1 toolchain doesn't provide rfkill headers, as demonstrated by busybox with the rfkill tool enabled:

| miscutils/rfkill.c:23:26: error: linux/rfkill.h: No such file or directory

Hello everyone,

I am trying to build my yocto minimal image using Sourcery_G++_Lite toolchain:
arm-none-linux-gnueabi-g++ (Sourcery G++ Lite 2010.09-50) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I've cloned meta-sourcery (master branch) to the yocto (master branch) directory and prepend the path of the meta-sourcery in bblayers.conf. Also I've set EXTERNAL_TOOLCHAIN = "/opt/Sourcery_G++_Lite" and EXTERNAL_TARGET_SYSTEMS = "arm-none-linux-gnueabi"
in the local.conf file.

When I build a minimal image I receive the following warning:

WARNING: QA Issue: /usr/lib/glibc-external/getconf/POSIX@underscore@V7@underscore@ILP32@underscore@OFF32_glibc-external contained in package glibc-external requires libgcc_s.so.1, but no providers found in its RDEPENDS [file-rdeps]
WARNING: QA Issue: /usr/sbin/nscd_nscd contained in package nscd requires libgcc_s.so.1, but no providers found in its RDEPENDS [file-rdeps]
WARNING: QA Issue: /usr/bin/locale_glibc-external-utils contained in package glibc-external-utils requires libgcc_s.so.1, but no providers found in its RDEPENDS [file-rdeps]

and after deploying the image on a board I receive the following error:
VFS: Mounted root (nfs4 filesystem) on device 0:14. devtmpfs: mounted Freeing init memory: 260K 192.168.10.1-ma used greatest stack depth: 5300 bytes left /sbin/init: error while loading shared libraries: unexpected reloc type 0x0d init used greatest stack depth: 4320 bytes left Kernel panic - not syncing: Attempted to kill init! Backtrace: [<c0059ecc>] (dump_backtrace+0x0/0x118) from [<c03f405c>] (dump_stack+0x20/0x24) r6:000010e0 r5:c055eabc r4:c058ad60 r3:c058b1a8 [<c03f403c>] (dump_stack+0x0/0x24) from [<c03f40d4>] (panic+0x74/0x194) [<c03f4060>] (panic+0x0/0x194) from [<c008a5a4>] (complete_and_exit+0x0/0x2c) r3:00000000 r2:df859f60 r1:df859f60 r0:c04c89a4 r7:df856000 [<c0089ec4>] (do_exit+0x0/0x6e0) from [<c008a828>] (do_group_exit+0x50/0xbc) r3:00000000 r2:df859f60 r1:df859f60 r0:c04c89a4 r7:df856000 [<c0089ec4>] (do_exit+0x0/0x6e0) from [<c008a828>] (do_group_exit+0x50/0xbc) r7:000000f8 [<c008a7d8>] (do_group_exit+0x0/0xbc) from [<c008a8b4>] (sys_exit_group+0x20/0x28) r4:41424284 r3:0000007f [<c008a894>] (sys_exit_group+0x0/0x28) from [<c0055ae0>] (ret_fast_syscall+0x0/0x30)

But if I copy libraries manually from the Sourcery toolchain (/opt/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib) to the image's rootfs lib/ directory everything works fine.

Could you please help me?

We should:

1. Determine which files from the external toolchain are ELF binaries (see package.bbclass for that)
2. Grab any path from .gnu_debuglink, use this to determine any .debug files to extract, in case the external toolchain has done a debug data split the way we do
3. Ensure we either install it to the expected path given the current debuglink, or alter it to match our configuration and expectations. Currently, for example, the Sourcery G++ toolchain does a debug split, but in a style that doesn't match any of the existing debug styles in OE
4. Go through the debug info, checking for existing source files and extracting those as well, and ideally moving them into /usr/src/debug and adjusting the paths in the debug info to match

https://layers.openembedded.org/layerindex/updates/37925/
ERROR: Issues found on branch master:
meta-sourcery: Failed to add since LAYERDEPENDS is not satisfied

and then edit meta-sourcery layer to add it to layer dependencies.

(Two years since last update because of failing this dependency)

Similarly to this bugreport:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4907

it would be nice to get any idea how to use this layer, i.e. what I am supposed to put into the build configuration files after integrating this layer into our project, and so forth.

This is just a mirror of the following report for visibility:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4923

Currently, binutils in oe-core is patched to support armv5e (gcc already supported it). This patch isn't applied in the binutils in Sourcery G++. As a result, any builds that pass -march=armv5e will fail, so any machine with DEFAULTTUNE set to armv5te will fail. Currently, the tunings are configured to leave the 't' off of ARMPKGSFX_THUMB when ARM_INSTRUCTION_SET != 'thumb'.

We can work around it for any machines that don't need the dsp support by setting DEFAULTTUNE to armv5t rather than armv5te, since then -march=armv5 will be passed, which is supported.

Alternatively, we can override ARMPKGSFX_THUMB for armv5 to ensure that the 't' is always included when thumb is supported, even when thumb isn't being used.

In meta-sourcery, we bypass pseudo on gcc/g++ to avoid an issue with Sourcery G++ (a temporary file is written to /tmp, a global path, with the current username in the path, and under pseudo that username doesn't match up with the actual ownership of the file, so doing builds by multiple users on the same machine will result in failures). This isn't generally a problem, as those usually don't write to ${D} directly, but in the case of ptest, we often copy entire test subtrees of ${S} into ${D}, which retains ownership, and those files were written with host ownership, hence our host-user-contaminated QA test fails. To work around this, we can add a postfunc to do_install_ptest_base to fixup ownership.

Obviously this isn't ideal. I intend to break up this layer into multiple layers eventually, to separate bits which are generally useful for any external toolchain from bits which are truly Sourcery G++ specific.

See '[OE-core] [PATCH v2] gcc-runtime: Remove libgfortran data from receipe':

Remove libgfortran packages from PACKAGES list as long as libgfortran
has separate receipe since commit

5bde5d9b39ea67f19a1a6aedd0c08c6cfedcbe5f
gcc: Allow fortran to build successfully in 4.8

Given there is:
remotes/origin/danny
remotes/origin/dora
remotes/origin/master

it would be nice to know the refpoint for the dylan branch as well.

ERROR: Layer 'sourcery' depends on layer 'external-toolchain', but this layer is not enabled in your configuration

I am trying to port a third-party toolchain on NXP chips, but this issue has occurred. How should I solve it?

I doubt we want to checksum the entirety of the toolchain, but right now the sanity check triggers solely based on the external toolchain path, so if the contents of that path change, it won't re-run the sanity test. At a minimum we could checksum the gcc binary, or just naïvely go based upon the modification timestamp of the directories we care about.

libgcc-s-dev generated by external-sourcery-toolchain should include more binaries. Compare:

Original libgcc-s-dev from OE:

drwxrwxrwx root/root         0 2015-01-31 00:07 ./
drwxr-xr-x root/root         0 2015-01-31 00:06 ./usr/
drwxr-xr-x root/root         0 2015-01-31 00:06 ./usr/lib/
lrwxrwxrwx root/root         0 2015-01-31 00:06 ./usr/lib/arm-oe-linux -> arm-oe-linux-gnueabi
drwxr-xr-x root/root         0 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/
drwxr-xr-x root/root         0 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/
-rw-r--r-- root/root      2632 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/crtbeginS.o
-rw-r--r-- root/root      2524 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/crtbeginT.o
-rw-r--r-- root/root      2196 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/crtbegin.o
-rw-r--r-- root/root   5808530 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/libgcc.a
-rw-r--r-- root/root      1065 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/crtend.o
-rw-r--r-- root/root      1065 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/crtendS.o
-rw-r--r-- root/root     75528 2015-01-31 00:06 ./usr/lib/arm-oe-linux-gnueabi/4.9.1/libgcc_eh.a
drwxr-xr-x root/root         0 2015-01-31 00:06 ./lib/
-rw-r--r-- root/root       132 2015-01-31 00:06 ./lib/libgcc_s.so

libgcc-s-dev from meta-sourcery:

drwxrwxrwx root/root         0 2015-03-16 15:26 ./
drwxr-xr-x root/root         0 2015-03-16 15:25 ./lib/
-rw-r--r-- root/root       132 2014-07-29 19:22 ./lib/libgcc_s.so

Noticed by @vsitdikov .