linux/poky.git/meta/recipes-devtools/gcc/gcc-runtime.inc, branch dunfell-next

nativesdk-gcc-runtime: enable building libstdc++.a

2020-05-05T07:45:30+00:00

(From OE-Core rev: 217e8f587792b2fe25aead085ddc533d4100cd7a) Signed-off-by: Jeremy Puhlman Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

gcc-runtime: apply ARM specific workaround to big-endian ARM too

2020-03-29T11:05:31+00:00

(From OE-Core rev: 633010f7c9f369565fd43465a857ad5680405e11) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

newlib: Enable building libstdc++ for newlib based toolchains

2020-01-19T23:49:39+00:00

Some baremetal applications might require support from libstdc++ On newlib based toolchains, libstdc++ can be built as a static library that applications can then link against it. Pass libsdtc++-(static)dev to LIBC_DEPENDENCIES allowing the library to be present for cross compilation as well as on sdk builds. (From OE-Core rev: 18af9ecef6e247519d8a1573e32208bb69cf81fe) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie

gcc-cross.inc: Prevent native sysroot from leaking into configargs.h

2019-11-29T17:43:40+00:00

Prevent the native(sdk) sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc --version'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. The sysroot path is replaced with a generic "/host" prefix which represents the host sysroot (e.g. native or nativesdk). (From OE-Core rev: 84a78f46d59447eeec3d69532a7506148f64c979) Signed-off-by: Nathan Rossi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc-runtime: Package libstdc++.a-gdb.py

2019-11-27T13:25:18+00:00

There is python gdb script for static libstdc++ archives as well fixes ERROR: gcc-runtime-9.2.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/lib/libstdc++.a-gdb.py (From OE-Core rev: 9becb6c1ea68096930fe77cc0e4126ff204d0592) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-runtime: Add do_check task for executing gcc test suites

2019-09-06T11:45:47+00:00

Add a do_check task to implement execution of the gcc component test suites. The component test suites require execution of compiled programs on the target. The implementation provided allows for execution testing against a host via SSH or within the local build environment using qemu linux-user execution. The selection of execution is done via the TOOLCHAIN_TEST_TARGET variable, and configuration of the remote host is done with the TOOLCHAIN_TEST_HOST, TOOLCHAIN_TEST_HOST_USER and TOOLCHAIN_TEST_HOST_PORT variables. By default the do_check task will execute all check targets, this can be changed by setting MAKE_CHECK_TARGETS to the desired test suite target (e.g. check-gcc or check-target-libatomic). (From OE-Core rev: 9d5d680baa91b34dc97641f98856a51d1bb060c1) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie

gcc-runtime: Move content from gcclibdir into libdir

2019-08-14T16:33:49+00:00

OE does not use the traditional /usr/lib/gcc prefix to store gcc-runtime it basically is moved into libdir, however some newer files were installed by newer versions of gcc especially libgomp ( omp.h openacc.h ) into gcclibdir, so we have content in both directories, this confuses other tools which are trying to guess the gcc installation and its runtime location, since now we have two directories, the tools either choose one or other and we get inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc This change ensures that OE ends up with single valid location for gcc runtime files Move more common bits into common inc file (From OE-Core rev: e9e5744ba8b0d43c8b874d365f83071ce20bf0a1) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-runtime.inc: create the correct directory before creating the symlinks in it

2019-06-21T14:32:36+00:00

* since commit b071a1a209556158bcfcc20e3c8bd4b15373767c Author: Changqing Li Date: Tue Jun 18 15:46:56 2019 +0800 gcc-runtime: fix C++ header mapping for n32/x32 tune gcc-runtime.do_install is failing with: ln: failed to create symbolic link 'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits': No such file or directory WARNING: exit code 1 from a shell command. ERROR: Function failed: do_install (log file is located at work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049) There is only empty directory without the -gnueabi suffix: work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/ and work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/ bits ext * make sure to create correct directory (with -${TARGET_OS suffix instead of -linux suffix) before creating the symlinks in it (From OE-Core rev: 41cbf5dc203ba74b06cb4890e1022f3f02fbd6fd) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

gcc-runtime: fix C++ header mapping for n32/x32 tune

2019-06-19T11:46:44+00:00

The SDK was unable to find the C++ header pieces correctly since it's using a generic compiler, not one specifically targeting the multilib vendor prefix and default tune. This adds the right mapping to ensure SDKs work as expected. And fix problem in below configurations: multilib configuration 1: MACHINE="qemumips64" MULTILIBS ?= "multilib:lib32 multilib:libn32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips" DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32" MULTILIB_GLOBAL_VARIANTS_append = " libn32" require conf/multilib.conf ignoring nonexistent directory "/sysroots/mips64-poky-linux/usr/include/c++/8.2.0/mips64-poky-linux/32 multilib configuration 2: MACHINE="qemumips64" MULTILIBS = 'multilib:lib64 multilib:lib32' DEFAULTTUNE = 'mips64-n32' DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64' DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2' require conf/multilib.conf For this configuration: for target gcc-runtime, need to create symlink like mips64-poly-linux --> mips64-poky-linux-gnu32 for target lib64-gcc-runtime, need to create symlink like mips64-poly-linux/32 --> mips64-pokymllib64-linux in order to avoid conflict during populate_sdk, create symlink for subfoler bits/ext for target gcc-runtime, this is ugly, but seems no better way to cover all kinds of configuration. single lib configuration: MACHINE="qemumips64" DEFAULTTUNE = "mips64-n32" (From OE-Core rev: b071a1a209556158bcfcc20e3c8bd4b15373767c) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie

gcc-runtime: Add --cache-file to EXTRA_OECONF

2019-01-24T17:45:25+00:00

This can save configure time since it runs configure multiple times: $ time bitbake gcc-runtime -cconfigure 60s -> 54s Saved 6s (From OE-Core rev: 48cc7179ffeb89adf1ba5212338b958684e43962) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie