RISC-V multilib currently doesn't work at all. We could disable multilib for
the riscv platform but that would then behave differently to all our others.
Instead, copy the non-multilib config over the multilib config for now for
riscv, meaning we can keep the platforms similar.
This isn't quite enough as the triplet specific c++ headers are in the wrong
place leading to compiler issues and testimage failures. Work around that too
until someone adds full multilib support for the platform (if desired).
(From OE-Core rev: 3081f62c18fcee642ab43efa717c8f71d51ae587)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libstdc++.modules.json is new file in libstdc++ from GCC-15
it is the module mapping file used in C++ projects that
utilize C++20 modules
(From OE-Core rev: bbfe7ee5b64618649eb8aff753b444c97313e617)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding a "network" task specific flag which then triggers networking to
be enabled for this task, it is otherwise disabled which will cause
failures while running oe-selftest.
Fixes the following issues while running oe-selftest for gcc:
1)ssh: connect to host X.X.X.X port 22: Network is unreachable.
2)Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf.
(From OE-Core rev: 35782416823fa863d26a338256f642f6bc480a96)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enables usage of TCLIBC=picolibc extending OE functionality to build and use
picolibc based toolchains to build baremetal applications.
Picolibc is a set of standard C libraries, both libc and libm, designed for
smaller embedded systems with limited ROM and RAM. Picolibc includes code
from Newlib and AVR Libc, but adresses some of newlibs concerns, it retains
newlibs directory structure, math, string and locale implementations, but
removed the GPL bits used to build the library, swiches old C style code for
C18 and replaces autotools with meson.
This patch adds a picolibc recipe for the C library, a picolibc-helloworld
recipe that contains an example application and a testcase that builds it.
Picolibc can be built for ARM and RISCV architectures, its been tested both
for 32 and 64 bits, the provided example recipe produces the following output:
hello, world
Runqemu does not automatically show any output since it hides QEMU stderr which
is where the QEMU monitors output is directed to when using semihosting, but,
manually running the same QEMU command does work properly.
(From OE-Core rev: c7535ecaccb72ef21a61f9aec5c68e61fb4f6fb6)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
g77/f77 has been removed from gcc 4.0.0 via commit:
* b4117c30610 Makefile.def, [...]: Remove all mention of libf2c.
When set
FORTRAN = ",f77"
it complains with error:
| The following requested languages could not be built: f77
| Supported languages are: c,c,c++,fortran,go,lto,m2,objc,obj-c++
So remove g77/f77 from gcc recipes.
[1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b4117c30610
(From OE-Core rev: 6469c6a00066af24c87ec5dd7994ebbc610c3782)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: gcc-runtime-14.1.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package:
/usr/share/info
/usr/share/info/libgomp.info-2
/usr/share/info/libgomp.info-1
(From OE-Core rev: 4f73ddd6c276dcd579d2113db1974d446dbf7751)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When debugging a C++ program on target using libcstdc++, gdb does not
find the pretty printer python support, this is because the init file is
installed into /usr/lib which is excluded from gdb's default list of
directories to load config's from, where as defaults to load from
datadir is still on, it therefore does not load this file
warning: File "/usr/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
This leaves the libstdc++ pretty-printers disabled even though added via
IMAGE_INSTALL += "gcc-runtime-dbg"
Comment on adding missing runtime dependency on datetime python module for the pretty
printer to work/load successfully.
Once the pretty-printer gdb file is moved out of libdir, it may become
empty therefore delete it if its empty.
(From OE-Core rev: d24e16d192f21aa68b5274496efaba1d913f37c2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debian 12 no longer supports replacing dash with bash as default shell.
Therefore to achieve compatibility with Debian 12, all bashisms need
to be removed.
Shell comparison via == gives an error with dash and thus the condition
is always false.
(From OE-Core rev: 3723b26f82219ff71823335d550dbf29086d63d4)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't really need to keep S and B separate for debug source purposes
and there shouldn't be source references in WORKDIR that isn't S and B
either.
Separating these out simplifies the shared-work directory handling for
gcc and should also help fix external source usage. Therefore handle
S and B in DEBUG_PREFIX_MAP separately and clean up other code.
Indentation is reduced here as it is introduced on every compiler
commandline so minimising it is helpful.
(From OE-Core rev: c39b5020b8705d17e3745c41e38d0f99a1ac94cf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code was some of the earliest reproducible build work we did. To
correctly handle the encoding of file paths, we used relative build
paths to run configure which resulted in relative build paths in the
binaries.
We now have more modern approaches used elsewhere with the prefix remapping
options. These work best with absolute paths, not relative ones. As such,
drop the relative path mangling and switch to using prefix mapping
exclusively on absolute paths.
This makes the code matc the rest of the system and triggers the correct
code to be added in /usr/src/debug.
We have to include both file-prefix and debug-prefix since the assembler
only looks at debug-prefix.
(From OE-Core rev: 309e5d8bb56eb8599d756831f0bd38e6a50cfb05)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
some standalone targets e.g. riscv64-elf disable shared linking for
baremetal ELF ABI in ld, therefore lets make it a static library
(From OE-Core rev: 3c6219dfcbcbde314648ba8cc54a90b32ea1c952)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This disables tests for runtime system specific functions like fcntl
there is no other change seen
+configure:77372: checking for fcntl
+configure:77372: result: yes
In libsttdc++ configure log outputs.
[YOCTO #14803]
(From OE-Core rev: 586b6239252ecf2711930b60f7f0f617e38ac737)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a dummy shared object therefore reduce dependencies further by
not requiring the C startup files, we wont use this shared library for
anything useful anyway
(From OE-Core rev: e1c4953f5587621d4911416c2e9350ad0c27b296)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes reproducibility issues with multilibs were a different recipe
specific sysroot is used which was leaking into debug symbols in libraries.
(From OE-Core rev: f442edf51e256bd315bd8e4ac4d9fa12b8e9e092)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If gold is enabled as the default linker, it errors trying to link
to our dummy library empty file and this turns off things which should
be present in libstdc++.
For example, _GLIBCXX_HAVE_S_ISREG isn't defined and HAVE_S_ISREG in
libstdc++-v3/config.h isn't set properly.
Instead of just creating an empty file, create an empty elf binary
instead which addresses the issue.
(From OE-Core rev: 2070bcd10aa3a05c96c8501c6a8c1e129fb1d440)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
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
1e42d5c637
(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>
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>
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>
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>
