The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks when libdir is '/usr/lib/tuple', leading to libraries ending up in '/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the prefix instead.
(From OE-Core rev: e58d5521c7bae8daafdac85754545be176550a02)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve reproducible build of:
openssl-staticdev
openssl-dbg
libcrypto
There are two main causes that prevent reproducible build, both related to
the generated file "buildinf.h":
1. "buildinf.h" contains build host CFLAGS, containing various build
host references. We need to pass sanitized CFLAGS to the script
generating this file ("mkbuildinf.pl". )
2. We also need to modify the script "mkbuildinf.pl" itsel in order to
generate a build timestamp based on SOURCE_DATE_EPOCH, if present in
the environment.
(From OE-Core rev: 6c556ed3553d8f5e75d65cd7db92b26df43846b7)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 7baba7a19c5610a63ccbfd6a2238667772b32118)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop upstreamed 0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
Rebase a couple more patches (via devtool upgrade).
(From OE-Core rev: 8a79b8619ce797d5395989e7bb804bc2accfbb14)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
(From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
(From OE-Core rev: e76dcfbd6e1ad6fc147a0607dcdaf8e7ea98b610)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-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>
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
(From OE-Core rev: edf9686be28fc321886d48043bcb4ef5b2c00c1d)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-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>
When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
server using the affected binary fails with:
ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect signature
Backport upstream bugfix:
https://github.com/openssl/openssl/issues/4659
(From OE-Core rev: 977db3843b629112539d3eb766c845127c0de497)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-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>
Deals with two CVEs:
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
(From OE-Core rev: a200115c769eff4b9b0241d54ed5ad86da08fdbc)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-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 patch works around a rare parallel build race condition using
the force option when soft linking.
The error seen is:
ln: failed to create symbolic link 'libssl.so': File exists
make[4]: *** [Makefile.shared:171: link_a.gnu] Error 1
make[4]: Leaving directory
'/.../build/tmp-glibc/work/x86_64-linux/openssl-native/1.0.2k-r0/openssl-1.0.2k'
Just add the -f flag to the platform independent soft link code to
avoid the collision. This is reasonable since this Makefile removes
the link target before creating a new soft link. The Makefile was
written this way to support platforms that don't allow forcing a
softlink to overwrite an existing link. Only builds on Linux are
supported so that's not a requirement for oe-core recipes.
The openssl team is rewriting their build files so it's not appropriate
for openssl upstream and fixing the root cause of the race condition
was also not pursued.
(From OE-Core rev: c60288aba70635238094c6b813228b31e0715db9)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
openssl 1.1 broke 3rd party layers a lot more than was expected; let's flip
the switch at the start of next development cycle.
Add a PROVIDES = "openssl10" to openssl 1.0 recipe; any dependency that is
not compatible with 1.1 should use that in its DEPENDS, as the 1.0
recipe will later be renamed back to openssl10. This does not always work:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140957.html
but for many recipes it does.
(From OE-Core rev: 5585103c195104e85ed7ac1455bef91b2e88a04d)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: openssl-1.1.0f-r0 do_package_qa: QA Issue: /usr/lib/openssl/ptest/fuzz/helper.py contained in package openssl-ptest requires /usr/bin/python, but no providers found in RDEPENDS_openssl-ptest? [file-rdeps]
ERROR: openssl-1.1.0f-r0 do_package_qa: QA Issue: /usr/lib/openssl/ptest/test/certs/mkcert.sh contained in package openssl-ptest requires /bin/bash, but no providers found in RDEPENDS_openssl-ptest? [file-rdeps]
(From OE-Core rev: 7e70d0673df20669edd18b79ae065d8c2f655b8a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The package resolver failes to assemble images because some of the man
pages in openssl10 conflict with the openssl package. In the case
where you want openssl, openssh and the documentation installed in the
same system you will see the failure.
The work around is to rename all the openssl10 man pages and symlinks
to have a prefix of openssl10-.
(From OE-Core rev: bb837cae92472b294ac886b121b2249e4314439f)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing openssl 1.0 recipe is renamed to openssl10; it will
continue to be provided for as long as upstream supports it
(and there are still several recipes which do not work with openssl
1.1 due to API differences).
A few files (such as openssl binary) are no longer installed by openssl 1.0,
because they clash with openssl 1.1.
(From OE-Core rev: da1183f9fa5e06fbe66b5b31eb3313d5d35d11e3)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Dropped obsolete patches, because the new version contains them:
- fix-cipher-des-ede3-cfb1.patch
- openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
2. LICENSE checksum change due to copyright years and wording tweak.
3. Test binaries (x86-64) are included in source code. So remove those
only for ptest.
(From OE-Core rev: 64ec18d7e13d310e5e44080a04b3f2181ea96ae3)
Signed-off-by: Changhyeok Bae <changhyeok.bae@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds or fixes the Upstream-Status for all remaining patches missing it
in OE-Core.
(From OE-Core rev: 563cab8e823c3fde8ae4785ceaf4d68a5d3e25df)
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>
Commit 7933fbbc637 "Security fix Drown via 1.0.2g update" included
a version-script change from Debian that was an ABI change. It did
not include the soname change that Debian did so we have been calling
our ABI 1.0.0 but it really matches what others call 1.0.2.
Bump SONAME to match the ABI. In practice this changes both libcrypto
and libssl sonames from 1.0.0 to 1.0.2.
For background: Upstream does not do sonames so these are set by
distros. In this case the ABI changes based on a build time
configuration! Debian took the ABI changing configuration and bumped
soname but e.g. Ubuntu kept the deprecated API and just made it not
work, keeping soname. So both have same version of openssl but support
different ABI (and expose different SONAME).
Fixes [YOCTO #11396].
Thanks to Alexander Larsson et al for detective work.
(From OE-Core rev: 1b430eef7131876bc735c22d66358379b0516821)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 991620f3962a9917fa99abb5582f4b72ebd42a3d.
The commit breaks openssl-native (you can no longer generate keys
because it can't find the configuration file). Also the idea that we
would install configuration files normally but then add the symlinks
pointing to them in a postinstall feels wrong.
Fixes [YOCTO #11296]. The bug contains an alternative fix but I'm
sending a revert as I cannot fully understand the motive of the
original patch. See also discussion in
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135176.html
(From OE-Core rev: b192daef5d1e7f3501c533b92dc75e2d996afc13)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the
default openssl version. Openssl 1.0 will stay but will be renamed
to openssl10, and eventually it will be removed (hopefully much
sooner than the official end of support date of Dec 2019, as we do not
want an unsupported openssl version in supported Yocto releases).
There are several recipes that are not API compatible with 1.1; some
of them will eventually be fixed, but others will never be (such as Qt4).
To avoid breaking such recipes when openssl 1.1 is added to oe-core,
let's provide "openssl10" already now and change the recipes to depend
on that where necessary; Qt4 is a particularly pressing issue as it is
causing failures on the autobuilder with my work in progress
openssl 1.1 branch, and so I'm not able to see what else would fail
later in the build process.
(From OE-Core rev: cffc3a88608bd295eb1220fadae56eb4676414df)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 'c8da8ce openssl: Fix build with clang' introduced a regression.
do_compile fails when building with gcc/thumb2.
Note that I did not test if it still builds with clang.
Prevents the following when building with thumb2:
| ghash-armv4.S: Assembler messages:
| ghash-armv4.S:88: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r2,r3]'
| ghash-armv4.S:98: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:98: Error: thumb conditional instruction should be in IT block -- `ldrplb r8,[r0,r3]'
| ghash-armv4.S:105: Error: thumb conditional instruction should be in IT block -- `eorpl r12,r12,r8'
| ghash-armv4.S:107: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:108: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'
| ghash-armv4.S:144: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:144: Error: thumb conditional instruction should be in IT block -- `ldrneb r12,[r2,#15]'
| ghash-armv4.S:231: conditional infixes are deprecated in unified syntax
| ghash-armv4.S:231: Error: thumb conditional instruction should be in IT block -- `ldrplb r12,[r0,r3]'
| ghash-armv4.S:248: Error: thumb conditional instruction should be in IT block -- `andpl r14,r12,#0xf0'
| ghash-armv4.S:249: Error: thumb conditional instruction should be in IT block -- `andpl r12,r12,#0x0f'
(From OE-Core rev: 65cfb24033278fd4fb27013d3272394197649ca2)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The OpenSSL recipe tried to workaround the -e make flag (overriding
variables from the environment). And when the -e flag was dropped as
the global default, it was specifically added for OpenSSL. This is
unnecessary, as only the value of ${AR} seems to be affected, and that
can be handled correctly by OpenSSL's build system if we just let it.
(From OE-Core rev: 537a404cfbb811fcb526cdb5f2e059257de6ef13)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
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 patch was added to fix a CVE, but wasn't actually added to SRC_URI:
CVE: CVE-2004-2761
The MD5 Message-Digest Algorithm is not collision resistant,
which makes it easier for context-dependent attackers to
conduct spoofing attacks, as demonstrated by attacks on the
use of MD5 in the signature algorithm of an X.509 certificate.
(From OE-Core rev: 8791800f84321b3f46772bc2d9e4f754e6213946)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Symlinking the openssl configuration file at install time results in
errors when overriding it using an external package which also provides
openssl-conf. This should be done as a postinstall task for such
packages.
(From OE-Core rev: 991620f3962a9917fa99abb5582f4b72ebd42a3d)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Absolute path symlinks are a bit of a pain for sstate and the native versions
of these recipes currently contain broken symlinks as a result. There are
only a small number of problematic recipes, at least in OE-Core, namely the
three here.
Rather than trying to make sstate handle this magically, which turns out to
be a harder problem than you'd first realise, simply make the symlinks relative
early in the process and avoid all the problems.
The alternative is adding new complexity to sstate which we could really
do without as without the complexity, you can't always tell where the
absolute symlink is relative to (due to prefixes used for native sstate).
(From OE-Core rev: e478550c8cd889f12e336e268e9e3b30827bf840)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 target was being configured for linux-generic64 but openssl has
linux-aarch64 target. Change to use linux-aarch64 as default.
(From OE-Core rev: 13e9a692510151383bc3243c3917154896b0e049)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes
| /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32 against undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value
(From OE-Core rev: 0a19e72081771fca8ed94fb2a2a8996fd3dce00c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use SHA256 as default digest for OpenSSL instead of MD5.
CVE: CVE-2004-2761
The MD5 Message-Digest Algorithm is not collision resistant,
which makes it easier for context-dependent attackers to
conduct spoofing attacks, as demonstrated by attacks on the
use of MD5 in the signature algorithm of an X.509 certificate.
Upstream-Status: Backport
Backport from OpenSSL 2.0 to OpenSSL 1.0.2
Commit f8547f62c212837dbf44fb7e2755e5774a59a57b
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(From OE-Core rev: f924428cf0c22a0b62769f8f31f11f173f25014f)
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: T.O. Radzy Radzykewycz <radzy@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script claims to be a /bin/sh script, but it uses
a bashism:
from checkbashisms:
possible bashism in meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh line 151 (should be 'b = a'):
if [ "x/" == "x$( echo ${FILE} | cut -c1 -)" ]
This causes build issues on systems that don't have
/bin/sh symlinked to bash:
Updating certificates in ${WORKDIR}/rootfs/etc/ssl/certs...
<builddir>/tmp/sysroots/x86_64-linux/usr/bin/c_rehash: 151: [: x/: unexpected operator
...
Fix this by using POSIX shell syntax for the comparison.
(From OE-Core rev: 0526524c74d4c9019fb014a2984119987f6ce9d3)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Reviewed-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The c_rehash utility is supposed to be run in the folder /etc/ssl/certs
of a rootfs where the package ca-certificates puts symlinks to
various CA certificates stored in /usr/share/ca-certificates/mozilla/.
These symlinks are absolute. This means that when c_rehash is run
at rootfs creation time it can't hash the actual files since they
actually reside in the build host's directory
$SYSROOT/usr/share/ca-certificates/mozilla/.
This problem doesn't reproduce when building on Debian or Ubuntu
hosts though, because these OSs have the certificates installed
in the same /usr/share/ca-certificates/mozilla/ folder.
Images built in other distros, e.g. Fedora, have problems with
connecting to https servers when using e.g. python's http lib.
The patch fixes c_rehash to check if it runs on a build host
by testing $SYSROOT and to translate the paths to certificates
accordingly.
(From OE-Core rev: 5199b990edf4d9784c19137d0ce9ef141cd85e46)
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Deals with a CVE issue
Drops a patch applied upstream and no longer needed.
(From OE-Core rev: ee590ac736ca2a378605fa1272a1c57a1dbc7a57)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"make alltests" is sensitive to the timestamps of the installed
files. Depending on the order in which cp copies files, .o and/or
executables may end up with time stamps older than the source files.
Running tests then triggers recompilation attempts, which typically
will fail because dev tools and files are not installed.
"cp -a" is not enough because the files also have to be newer than
the installed header files. Setting the file time stamps to
the current time explicitly after copying solves the problem because
do_install_ptest_base is guaranteed to run after do_install.
(From OE-Core rev: 101e2a5e0b7822ca3de3d3a73369405c05ab3c5b)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This update fixes several CVEs:
* OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
* SWEET32 Mitigation (CVE-2016-2183)
* OOB write in MDC2_Update() (CVE-2016-6303)
* Malformed SHA512 ticket DoS (CVE-2016-6302)
* OOB write in BN_bn2dec() (CVE-2016-2182)
* OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
* DTLS buffered message DoS (CVE-2016-2179)
* DTLS replay protection DoS (CVE-2016-2181)
* Certificate message OOB reads (CVE-2016-6306)
Of these, only CVE-2016-6304 is considered of high
severity. Everything else is low. CVE-2016-2177 and CVE-2016-2178 were
already fixed via local patches, which can be removed now.
See https://www.openssl.org/news/secadv/20160922.txt for details.
Some patches had to be refreshed and one compile error fix from
upstream's OpenSSL_1_0_2-stable was required. The server.pem
file is needed for test_dtls.
(From OE-Core rev: d6b69279b5d1370d9c4982d5b1842a471cfd2b0e)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed when building on Debian-testing:
| Can't locate find.pl in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.2 /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at perlpath.pl line 7.
(From OE-Core rev: c28065671b582c140d5971c73791d2ac8bdebe69)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MIPS64 target was being configured for linux-mips which defaults to
MIPS32. Doesn't cause any issue as far as I can see but it would be
wiser to use the correct target configuration.
Also add MIPS64le configuration which is missing.
(From OE-Core rev: 0afec72913bc31d315cba079da317e8b28755ded)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Regarding the last commit about missing dependencies, another issue
was found. The problem was found, while ptest has been built with some
set extra settings. It means, when ptest is going to be built,
it is necessary to rebuild dependencies for test directory too.
(From OE-Core rev: 030142d0410bec85aeacfff6be27d5fed41ce808)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
