| Age | Commit message (Collapse) | Author |
|---|
|
In commit ceda3238 (meta/meta-selftest/meta-skeleton: Update LICENSE
variable to use SPDX license identifiers) all LICENSE variables were
updated to only use SPDX license identifiers.
This does the same for comments and other variables where it is
appropriate to use the official SPDX license identifiers. There are
still references to, e.g., "GPLv3", but they are then typically in
descriptive text where they refer to the license in a generic sense.
(From OE-Core rev: 165759dced7fbe73b1db2ede67047896071dc6d0)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The patch to gcc to disable use of libstdc++ when configuring the library
during gcc-runtime is old and there are perhaps better ways to do this now.
If removed, most builds still "work" but incorrect values for things like
atomic ops are found during configure. mips64 and ppc fail with on target
simple tests of g++ in testimage.
Instead we can create a dummy libstdc++ which allows the correct configure
test results to be obtained.
Discussed with upstream about the patch are ongoing, if accepted, we can
switch back to the commandline option if it is added in future.
(From OE-Core rev: 34b0edb0d3120c32063ff7e3dd52be20d60401d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Those were missed in previous rounds of automated and manual conversion.
(From OE-Core rev: 22f9c7268b542baf6cd8aa0e34c8fb7aa1579e08)
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libstdc++ uses assertion macros which use __FILE__ macros and
if (__builtin_expect(!bool(_Condition), false)) \
std::__replacement_assert(__FILE__, __LINE__, __PRETTY_FUNCTION__, \
#_Condition)
This ends up using absolute paths into build tree for the cases where
the charconv header is used, therefore replace the file prefix paths
with on-target paths to make them build dir independent
(From OE-Core rev: 972c50d6e46ee9dfba8b8ea3867ebdbf24001e6e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Current definition of SLIB is actually equal to S but is hardcoded, this
means when we have altered location of S, then the regexp for
DEBUG_PREFIX_MAP will not be effective, which could result in S being
emitted into debug_line sections. Simplify the maps to use S variable
instead of SLIB
Secondly, rename SLIB_NEW to REL_S to make it more appropritate to what
it represents
(From OE-Core rev: 2c8e130adb5d4d55ba732a042ec157498460ee29)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
configuration:
MACHINE ??= "qemux86-64"
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "core2-32"
IMAGE_INSTALL_append = " packagegroup-core-buildessential lib32-libstdc++ lib32-libstdc++-dev"
m32 compile failed on target:
cmd: gcc -m32 -v test.cpp -o test
output:
GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29590
ignoring nonexistent directory "/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0/x86_64-poky-linux/32"
ignoring nonexistent directory "/usr/lib64/x86_64-poky-linux/10.1.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../x86_64-poky-linux/include"
/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0
/usr/lib64/gcc/x86_64-poky-linux/10.1.0/../../../../include/c++/10.1.0/backward
/usr/lib64/gcc/x86_64-poky-linux/10.1.0/include
/usr/lib64/gcc/x86_64-poky-linux/10.1.0/include-fixed
/usr/include
End of search list.
GNU C++14 (GCC) version 10.1.0 (x86_64-poky-linux)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29590
Compiler executable checksum: bc3b2f3a33dad80e30112cf1235bf631
In file included from test.cpp:1:
/usr/include/c++/10.1.0/iostream:38:10: fatal error: bits/c++config.h: No such file or directory
38 | #include <bits/c++config.h>
| ^~~~~~~~~~~~~~~~~~
cannot find header since
/usr/lib64/gcc/x86_64-poky-linux/10.1.0/x86_64-poky-linux/32 is missing
fixed by link it to ../i686-poky-linux
(From OE-Core rev: 509022ea8db314dd9d010a478fd84d0234905c6b)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
mudflap was removed in gcc 4.9.
(From OE-Core rev: 6d649a07cfa0a89448caa67e4ca0a990973961b9)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libatomic has mind of its own when it comes to setting -march for arm64
which conflicts with -mcpu option we pass from environment in some cases
since we always pass -march/-mcpu in OE, its safe to remove this option
mcpu removal from cortex-a55 is no longer needed since the option
conflict is now removed from libatomic instead
(From OE-Core rev: a5331c5a8bbe63c6c2e56ebec496b28968d4663d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Package new gomp header acc_prof.h
* Package lto-dump which is a new tool in gcc10
* All Changes are here [1]
* Porting apps to gcc 10 help is here [2]
* Backport a patch to fix CET errors on cross builds
* Add patch to fix mingw libstdc++
[1] https://gcc.gnu.org/gcc-10/changes.html
[2] https://gcc.gnu.org/gcc-10/porting_to.html
(From OE-Core rev: 44c3881b18f74eb64379818fc150f94398fb8a49)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gcc-runtime/libatomic explicitly add -march=armv8-a+lse for all arch64
but cortex-a55 is armv8.2-a, which essentially conflicts, so let gcc
override it by not forcing the -mcpu option from TUNE_CCARGS
(From OE-Core rev: 882df891e13ce5c64718c364efb9ef2bf189eabf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: ef5cff3db22e911b7a6ecf3dac212903757b4df1)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 633010f7c9f369565fd43465a857ad5680405e11)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* since
commit b071a1a209556158bcfcc20e3c8bd4b15373767c
Author: Changqing Li <changqing.li@windriver.com>
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 <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 "<path>/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 <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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 <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libmpx is not supported any longer and infact has been removed
completely from gcc-9, see
https://github.com/gcc-mirror/gcc/commit/1e42d5c637e1b1f65dfddd0923dfb25676bb56e5
(From OE-Core rev: 547174fc834273af67a2f7e50a3cf6c8e3b900f4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For reasons lost in the depths of time, perhaps performane related,
we only have a dependency on libc at packaging time. This is too late,
as demonstrated by a recent build failure on non-IA builds where
the glibc 2.29 upgrade had been removed from the build:
ld: recipe-sysroot/usr/lib/../lib/libstdc++.so: undefined reference to `log@GLIBC_2.29'
libstdc++ should have been rebuilt but had not as the dependency
wasn't present.
Add the missing dependency to avoid this problem (and drop the other
form of dependency which is no longer needed).
(From OE-Core rev: 14c291e1fb6324da46885b69fbd7f01b3c6b053e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The libitm is not supported on ARC, so disable it
(From OE-Core rev: 6840f54cbac88e8a8f70384775771c4fda20b9c9)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libssp is implemented fully in glibc as well as in musl
so we really do not need the gcc version of this library
except may be for mingw, where we keep it enabled anyway
gcc in OE is built with the knowledge that C library
already provides libssp implementation, we should therefore
not need the gcc implementation of same.
libssp_nonshared piece is a detail which is needed when gcc
is the compiler, in glibc this is part of libc_nonshared.a
already and libc_nonshared.a is linked always when linking
with -lc becuase libc.so in glibc is actually a linker script
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )
which automatically links in the needed runtime bits, this however
is not the case for musl, where core SSP APIs are implemented in full
but compiler specific runtime isn't, for this we add a new package
called libssp_nonshared which generate the needed runtime stub
and gcc is already carrying patch to link to libssp_nonshared.a
on musl
This should fix a long standing problem where static PIE executable
were not buildable with OE since it was conflicting SSP implementation
one from C library and the other one from gcc and we end up with
duplicate symbol errors during linking.
Backport a patch from trunk which enhances enable|disable-libssp
to not only disable building libssp but also not emit the gcc
specs to use it for subsequent linking when stack-protector options
are used on compiler cmdline
(From OE-Core rev: 6c14f99936f8c8c9b9d9f40a6b0c69675ea9a566)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Remove various build host references from packages:
libstdc++
libstdc++-staticdev
gcc-runtime-dbg
The references are removoved by correctly setting various compiler
-fdebug-prefix-map settings. There are two main issues:
The default DEBUG_PREFIX_MAP variable references WORKDIR, however,
gcc sources are in a shared folder (work-shared)/
Additionally, DWARF info seems to store symlink names but gcc
seems to resolve symlink names referenced in -fdebug-prefix-map.
(From OE-Core rev: 04748af752b7f9d79ee4add67141d6c891f3bdbe)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 21caa8bcda93ce67ef58548f7b85d0569d13d0b9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some of these are clearly dead, e.g. one binutils patch reverts the effects
of the earlier one.
This also removes the uclibc site files. We now have mechanisms to allow these
to be extended from another layer should someone ever wish to do that.
(From OE-Core rev: e01e7c543a559c8926d72159b5cd55db0c661434)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Switch default compiler to gcc 7
(From OE-Core rev: 03bb12008891cf1a023aaddb6547da6d41d0cab0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Intel MPX was recently enabled on x86 (_append_x86) but that didn't
enable it on x86-64. Explicitly enable libmpx on x86-64 too.
(From OE-Core rev: 5111bd5e666408dbca7db0e6d664fe0103744253)
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package:
/usr/lib/libmpxwrappers.la
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
gcc-runtime: 1 installed and not shipped files. [installed-vs-shipped]
(From OE-Core rev: 3658da86e57dc87ac3957b05f853a7f1a56bfab2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Enabling building the Intel Memory Protection Extension library for x86.
Leave this disabled in musl builds as it doesn't build there yet.
(From OE-Core rev: 4b144b55acbd43b38d92d29829d8ec68ff372e9d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SDKPKGSUFFIX could only really be "nativesdk" and TARGET_SYS never contains
that so the code manipulating TARGET_SYS is pointless. I suspect this once
worked against MULTIMACH_TARGET_SYS which would be a different question but
it no longer does. Its been cut and pasted everywhere.
This patch cleans up the variable references to make things a little more
readable.
(From OE-Core rev: 5599cb72d17bce2ba6e2be16ef64d9a388bcfb25)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When we stashed the gcc build directory for use in generating the various runtimes
we were being lazy and just used the staging directory. With recipe specific
sysroots this means we're copying a large chunk of data around with the cross
compiler which we don't really need in most cases.
Separate out the data into its own task and inject this into the configure
step. We have to do that here since autotools will wipe out ${B} if it thinks
we're rebuilding and we therefore have to time its recreation after that.
This also takes the opportunity to remove some pointless (as far as I can tell)
conditionals from the do_install code.
(From OE-Core rev: dcf15ccf3cc9d55e77228ba8d526f967fc9791b4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Reduce duplication in MIPS variants now that the MACHINEOVERRIDES
variable is defined
(From OE-Core rev: c84c884da5007539ea290587c468f30c19f568e9)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Using the following setup (as specified in yocto sample code):
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:libx32"
DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32"
We fail to compile simple CPP programs because CPP cannot
find relevant header files, looking for them in a non-existing place.
To fix this, we create a symlink of the name CPP expects and point it to
the corresponding existing directory.
[YOCTO#10354]
[YOCTO#10380]
(From OE-Core rev: 9f9be229040f4f9a523a1e25afd78d5c3f4efc23)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add support for MIPS Release 6 ISA
(From OE-Core rev: 4c694d5bd29c406009332e3bd388e3f6a504d103)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch fixes the problem where the CPP compiler cannot find include files.
The compiler is configured to look for the files in places that do not exist.
When querying the CPP for search paths, we observe messages such as these:
multilib configuration:
MACHINE="qemumips64"
require conf/multilib.conf
MULTILIBS = "multilib:lib64 multilib:lib32"
DEFAULTTUNE = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
ignoring nonexistent directory "<path>/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/32
single lib configuration:
MACHINE="qemumips64"
DEFAULTTUNE = "mips64-n32"
ignoring nonexistent directory "<path>/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/
To fix this, create a symlink of the name CPP expects and point it to the corresponding "gnun32" directory.
[YOCTO#10142]
(From OE-Core rev: 55115f90f909d27599c686852e73df321ad1edff)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It's useful to know what the various libraries are that get produced by
gcc-runtime, as well as to have a specific SUMMARY for the recipe.
(From OE-Core rev: b8d5b4107c64784ea8c8f364a84c2bc76cd0b1b0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
for SDK use
We build SDKs such that gcc-cross-candian is built for only one
target *-*-linux and then use -muclibc or -mmusl to let it compile
code for other libc variants. This works fine when libc = glibc
however it does not work for c++ programs when libc != glibc since
there are c++ headers installed under ${includedir}/c++/${BINV}/${TARGET_SYS}
which is fine when gcc-runtime and gcc-cross-candian uses same --target options
gxx includedir searches in right triplet, but it fails with musl/uclibc
since gcc will look for glibc based triplet but gcc-runtime will install
them under musl/uclibc triplet.
This patch symlinks the musl/uclibc triplet to glibc triplet when libc != glibc
This fixes SDKs for musl/uclibc
(From OE-Core rev: fcaaabb401fffcda4db9a7d1f927a2a404e4776d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
LICENSE_${PN} doesn't apply to all gcc-runtime packages. Set LICENSE
instead. Without this fix, gcc-runtime packages such as libstdc++ are
excluded from rootfs for builds which blacklist GPLv3.
(From OE-Core rev: 9406a8ab8fd166b9d90b33b84b6d44f8672ab623)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception
As stated on https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h
header license:
...
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
...
(From OE-Core rev: 07db569a91e2aa8456624b340830c0e027cc6ead)
Signed-off-by: Helio Chissini de Castro <helio.castro@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This reverts commit 892fbe373c5cff7b2f28b58aa2508b47e53d3e63.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Disable libitm as it is not supported on MicroBlaze.
(From OE-Core rev: 18f127765f1cdcf531f29c58641a256c199d888c)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception
(From OE-Core rev: e24c8be86080bd67ef1c5aa3b9885396dc2774b2)
Signed-off-by: Helio Chissini de Castro <helio.castro@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The libitm is not supported on nios2, so disable it.
(From OE-Core rev: 9c67db02d89b48fe151a292faf65db81dd3baf50)
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Ross Burton <ross.burton@intel.com>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Walter Goossens <waltergoossens@home.nl>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libitm is already disabled for big endian MIPS, but needs to be
disabled for little endian MIPS targets too.
(From OE-Core rev: 421e8ac60ff6eb87e66ebeab6f14d74216386578)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
GCC 4.7 and newer have supported various automic operation directives,
however these have not been previously enabled.
(From OE-Core rev: 8cb4ac49677b1eae4047fc1abbd728f093a24b72)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The absolute path (/path/to/configure) caused __FILE__ to be
an absolute path.
If 'assert' invoked, it uses __FILE__, and build path would be in elf files.
In assert.h
...
.# define assert(expr) \
((expr) \
? __ASSERT_VOID_CAST (0) \
: __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))
...
Which triggered buildpaths QA issue:
...
| libgcc-5.3.0: File work/core2-64-poky-linux/libgcc/5.3.0-r0/packages-split/
libgcc-dev/usr/lib64/x86_64-poky-linux/5.3.0/libgcc.a in package contained
reference to tmpdir [buildpaths]
...
Use relative path to run configure can fix the problem.
[YOCTO #7058]
(From OE-Core rev: b806e4c004a7e10461fe7428fc130a5aa2528039)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libgfortran's build fails with "ld: cannot find -lquadmath" unless
libquadmath is added to gcc-runtime's RUNTIMETARGET
(From OE-Core rev: 80333155db8fa53fb52898c4312daa656de89c3b)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Peter Kjellerstedt
Richard Purdie
Denys Dmytriyenko
Khem Raj
Changqing Li
Adrian Bunk
Jeremy Puhlman
Andre McCurdy
Alejandro Enedino Hernandez Samaniego
Nathan Rossi
Martin Jansa
Robert Yang
Alexey Brodkin
Juro Bystricky
Mikko Ylinen
Zubair Lutfullah Kakakhel
Paul Eggleton
Helio Chissini de Castro
Ross Burton
Marek Vasut
Mark Hatle
Hongxu Jia
Ioan-Adrian Ratiu