shlibs is largely useless for allarch, the particular usecase where it
fails is when DISTRO_FEATURE is changing due to libc being different e.g.
Variable package_do_shlibs value changed:
-DISTRO_FEATURES{ldconfig} = Set
+DISTRO_FEATURES{ldconfig} = Unset
musl -> glibc or other way around 'ldconfig' gets added or deleted to
DISTRO_FEATURE set, neither this distro feature nor the shlibs processing
during packaging is of interest to allarch packages which are largely
arch independent scripts
(From OE-Core rev: 06602d56d1d311562144eafe459fcea36931a34c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This header is used by other apps e.g. ippool
glibc provides an internal version which it should not
(From OE-Core rev: fe24a5d24cb2f6af9b5dd20089e36afe99e88ea1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-lnsl needs to be removed even on glibc
(From OE-Core rev: 1d1e2f2c44aa6d02458cec720bee2818cbaa31ff)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop backported patches
Redo musl support patch such that it
can be applied universally
(From OE-Core rev: 94c23613724073f8def71bc9e76d7fd7a9f318ad)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will substitute the glibc nis module which
has been removed
Skip for non-glibc systems
(From OE-Core rev: cabef0916d860449bfbcc4ff596ec9f0029849e9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is no longer needed as gcc provided libssp
is not built
(From OE-Core rev: 6d025fe137e835ef2388f402d8d58728e62ed280)
Signed-off-by: Khem Raj <raj.khem@gmail.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>
libssp-nonshared is required on musl since
it does not implement the gcc runtime piece of
libssp, which actually it a gcc optimization to
reach to __stack_chk_fail
(From OE-Core rev: 72e254e99682aa0e2d01f20f50d9fbdeb77529b3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libssp-nonshared is a minimal gcc runtime piece which is needed
on non-glibc systems which do implement libssp APIs in libc
Use PIE flags to compile libssp_nonshared.a so it works with
security flags on as well
(From OE-Core rev: ddfab4d021d4daa5aefcd9cdd89d349bbd4b6869)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When trying to build meta-toolchain using TCLIBC = "baremetal"
bitbake throws an error due to a mising dependency:
ERROR: Nothing PROVIDES 'virtual/crypt'
glibc PROVIDES virtual/crypt but was skipped:
PREFERRED_PROVIDER_virtual/libc set to musl, not glibc
musl PROVIDES virtual/crypt but was skipped:
PREFERRED_PROVIDER_virtual/i586-poky-elf-libc-for-gcc set to baremetal,
not musl
libxcrypt PROVIDES virtual/crypt but was skipped: Recipe only applies in
nativesdk case for now
This is caused by the changes on commit:
29f65bda6d
nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
This is where the concept of virtual/crypt was introduced.
This patch adds virtual/crypt to ASSUME_PROVIDED on tclibc-baremetal,
providing the missing wiring to build meta-toolchain on baremetal
correctly.
(From OE-Core rev: 26a93d2bf7504bf5f3adb085ed2882ae1b1a3701)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new version contains an option to exclude certain tests to
run, example:
$ ptest-runner -e "perl"
(From OE-Core rev: e529b8a68741992a21be874b62c0ea37f51d6a19)
Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 1.9.6 fixes a number of issues since 1.9.4 release, mainly:
go1.9.5 (released 2018/03/28) includes fixes to the compiler, go
command, and net/http/pprof package.
go1.9.6 (released 2018/05/01) includes fixes to the compiler and go
command.
(From OE-Core rev: d4abc33c81f7aa33c432ead92ae16df01ebe36c8)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a minor release that fixes many important issues found since
1.10.1 release.
(From OE-Core rev: 844f3191cd3d8746b7b31cff83e7655958226520)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If alsa-utils configure is not passed a --with-udev-rules-dir option then
it defaults to using /lib/udev/rules.d. This meant that the hard-coded use
of ${D}/lib in do_install in 262e69c9c7acf0beb7bb6b96299e3c993c906434
worked correctly to remove the unwanted rules.
Subsequently, 0a4372705a030ca54ed420cdfec33d46ab93499c changed do_install
to use ${nonarch_base_libdir}, claiming to fix this in the usrmerge case.
This means that if udev is not present in PACKAGECONFIG and usrmerge is
present in DISTRO_FEATURES then the alsa-utils build system will install
the rules in ${D}/lib/udev/rules.d but do_install will attempt to remove
${D}/usr/lib, resulting in something like:
rmdir: failed to remove '.../tmp-glibc/work/i586-oe-linux/alsa-utils/1.1.5-r0/image/usr/lib': No such file or directory
To fix this, let's just tell configure to install the rules in a specific
known location when udev is disabled. This location can then easily be
cleaned up in do_install without doing any harm if udev is enabled.
Tested both with and without usrmerge in DISTRO_FEATURES and with and
without udev in PACKAGECONFIG.
(From OE-Core rev: 022b644e6ba2caa0b32ce3323621c07f78166234)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Cc: Phil Blundell <pb@pbcl.net>
Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If some other per value option was present than 'skip' or 'nick' then
a KeyError would occur. Ignoring such options matches the behaviour of
the old, Perl-based glib-mkenums.
(From OE-Core rev: ca6c82255fbf0ce359b6205c442e165219a3216e)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This isn't used by anything in oe-core (or in common use in general, only one
package in Debian depends on it), so remove it from oe-core.
(From OE-Core rev: 11ee7989b2f0709119c450819cd66bad70082a93)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove the backported patch 0001-Fix-a-strange-assert-typo-how-was-this-released-with.patch
* Remove the patch 0002-Don-t-set-up-m32-m64-we-do-that-ourselves.patch
as it already rewritten gcc to use toolset.flags again
as below:
commit 12decb3ce680031b915f69902795eec47224fc7d
Author: Steven Watanabe <steven@providere-consulting.com>
Date: Mon Jan 1 12:51:43 2018 -0700
Rewrite gcc to use toolset.flags again.
* Remove the hardcoded parallel build limit as the
mechanism already changed as below commit:
commit 316e26ca718afc65d6170029284521392524e4f8
Author: Steven Watanabe <steven@providere-consulting.com>
Date: Wed Apr 26 14:22:06 2017 -0600
Remove fixed limit to -j. Fixes#189.
* execunix.c: Replace select with poll.
* execnt.c: Use RegisterWaitForSingleObject when the number of jobs exceeds MAXIMUM_WAIT_OBJECTS.
Reference: 316e26ca71 (diff-c88fe8afebc632d0bef2bd5985137af2)
(From OE-Core rev: 358cf46ea4d01b7ad8c355fa103d4a6922cc0a88)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SSTATECLEANFUNCS mechanism was introduced to solve user/group
deletion problem. After RSS mechanism was introduced, there's no
need to do so.
There was a patch to remove these obsolete codes for useradd.bbclass,
but the codes in sstate.bbclass were not removed. So clean it up.
(From OE-Core rev: 215b83ce892a7002ed0b1bd7b82a08e67ae15121)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc "corei7" CPU type was last documented in gcc 4.8.x and has
been undocumented from gcc 4.9.x onwards:
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html
Although it still seems to be accepted by gcc 7.x, it's likely to be
deprecated and removed at some point. To preempt that, switch the
corei7 TUNE_CCARGS -march CPU type to "nehalem", which is the closest
replacement (and matches the CPU type already being passed to qemu).
Since the tune-corei7.inc include file is intended to cover a range
of CPUs from Nehalem onwards, switch the TUNE_CCARGS -mtune option
from "corei7" to "generic", which instructs gcc to produce code
optimized for the most common IA32/AMD64/EM64T processors.
(From OE-Core rev: 8d2f51e9b8d5b27fc61d148a6dd5f6ef5715d6e6)
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>
There's only one user of tar.inc (meta-gplv2 has its own copy), so
merge the .inc file into the tar recipe.
(From OE-Core rev: cce7b627f9046c15dde49c001481003cee33fc9c)
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>
Add mtd-utils-tests package which includes the test suites mtd-tests,
ubi-tests, fs-tests, etc.
These test suites are useful for verifying flash features or stress
testing.
(From OE-Core rev: 612d0468e34ca922b42a1176ab1e2feef72a2a13)
Signed-off-by: Martin Lund <malu@gomspace.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During Qemu guest migration, a destination process invokes ps2
post_load function. In that, if 'rptr' and 'count' values were
invalid, it could lead to OOB access or infinite loop issue.
Add check to avoid it.
(From OE-Core rev: 0d8f68fe43b4da1a0d356fe6bedb52b8f2a02081)
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>
