mentorembedded / meta-sourcery Goto Github PK
View Code? Open in Web Editor NEWYocto/OE metadata for the external sourcery g++ toolchain
Yocto/OE metadata for the external sourcery g++ toolchain
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.
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?
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.
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
We should:
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}"
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.
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.
This is just a mirror of the following report for visibility:
(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
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?
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.
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.
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 .
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!
See the following bugreport for details: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4921
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.
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)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.