Meson uses pkg_resources, which is part of setuptools.
(From OE-Core rev: 30a9dbc8a13928541ce6ff270801b8fd1c8af37e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop 0001-Correctly-install-the-shared-library.patch as upstream fixed the issue.
(From OE-Core rev: c9447be6efc89b2d6259bcd4237af482d47b389f)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop upstreamed gi-flags.patch and gtkdoc-flags.patch, rebase the rest.
(From OE-Core rev: 6cc5c57c38d2da37b4f15dea6e1fb97e3a0bae73)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libnolto_coregrind_a_OBJECTS is in libcoregrind_a_LIBADD, so the objects
should be ready before generate libcoregrind.a, otherwise there would be
failures:
i586-poky-linux-ar: libnolto_coregrind_x86_linux_a-m_libcsetjmp.o: No such file or directory
make[3]: *** [libcoregrind-x86-linux.a] Error 1
Add libnolto_coregrind_a_OBJECTS to EXTRA_libcoregrind_DEPENDENCIES to fix the
problem.
This is a race issue during parallel build.
(From OE-Core rev: 713d6978894269e5b463c3731c03da7e83956743)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE we do not build mutlib like gcc does it by default, this ensures
that mutlilib is virtually disabled for OE, since we hardly use same gcc
to build for multiple ABIs
This fixes cases in SDK where g++ is not able to find standard c++
include headers
(From OE-Core rev: badbeb01dd642d9d647d3760a3ce2aa39c3567da)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Append minor version to PV so recipe checker is happy
* Drop upstreamed patches
* Remove changelog from CVE patches, they dont apply and are in patch
log anyway
(From OE-Core rev: 550085bc092d773c8c481e238d0d3210466166dc)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We no longer have special "libc" for gcc so we can rely on plain
virtual/libc and reduce the complexity in the dependencies.
(From OE-Core rev: 122217b421f749b5fef52bea44ad6e04bc8f8d3a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Separated out from the previous commit for clarity, this simply drops
all the -inital pieces of gcc which are no longer needed after the
previous commit.
(From OE-Core rev: d84971928b68efddbdb6344b1021d998c9e26adb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need a libgcc to build glibc. Tranditionally we therefore build
a non-threaded and non-shared compiler (gcc-cross-initial), then use
that to build libgcc-initial which is used to build glibc which we can
then build gcc-cross and libgcc against.
Firstly, we can drop the glibc dependency from gcc-cross, *if* we make
two changes:
a) specify the minimum glibc version to support in a configure option
b) create a dummy limits.h file so that later when glibc creates one,
the headers structure has support for it. We can do this with a simple
empty file
Once gcc-cross is libc independent, we can use it to build both
libgcc-initial and then later libgcc.
libgcc-initial is tricky as we need to imitate the non-threaded and
non-shared case. We can do that by hacking the threading mode back to
"single" even if gcc reports "posix" and disable libc presence for the
libgcc-intial build. We have to create the dummy limits.h to avoid
compiler errors from a missing header.
glibc will fail to link with libgcc-initial due to a missing "exception
handler" capable libgcc (libgcc_eh.a). Since we know glibc doesn't need
any exception handler, we can safely symlink to libgcc.a.
With those changes, gcc-cross can be used in all places and we only need
one build of gcc for each architecture.
For some reason ifunc was being disabled on mips prior to these changes
but afterwards became enabled but caused assertion failures. This is
therefore disabled until we can debug that.
(From OE-Core rev: 62b7308b8c4d2b439a15a4f7cbc6f823077bb0be)
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>
We've had gcc 8.2 around for long enough that 7.3 can be removed now.
(From OE-Core rev: 20aea61385e1a53ac245353899277ba20104ed2f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are four functions using TFmode type (128bit) that isn't
available when building with musl. Move each of them from common
ppc64-fp.c to individual files referenced from t-float128 that used
when ldbl 128 enabled at configure time.
For gcc-7.3 if -mfloat128 is given -mfloat128-type must be given too.
Exclude ibm-ldouble.c when ldbl 128 isn't enabled at config time.
Build and boot tested with musl (no float128) and glibc (float128
and ibm128 on PowerPC64).
(From OE-Core rev: dec8e566810525563b33c2877d10db0a70965d6d)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building for powerpc64 using musl as C library we get preprocessor
macro redefinition errors since gcc-configure-common.inc adds #define
of STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 to
gcc/defaults.h after ones added by a patch that ensures target gcc
headers included.
Since gcc-configure-common.inc included in every gcc recipe either
directly or indirectly, do_configure task is not disabled/deleted for
any of them (except gcc-source.inc) and there is no precondition that
skips gcc/defaults.h patching in
gcc-configure-common.inc::do_configure_prepend() we can just remove
conflicting parts of mentioned above patch to have single place where
start files prefixes defined in do_configure() task.
(From OE-Core rev: 0622a4168aac627b44547f72fe93589cf1050e42)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building for powerpc 32bit with musl following error triggered
from do_configure:
checking for the platform triplet based on compiler characteristics... powerpc-linux-gnu
configure: error: internal configure error for the platform triplet, please file a bug report
This is caused by PLATFORM_TRIPLET != MULTIARCH mismatch since MULTIARCH
in case of musl is powerpc-linux-musl. Since triplet is used as part
module name as described in PEP-3149 to make fix less intrusive alias
powerpc-linux-musl to powerpc-linux-gnu to avoid possible runtime
(e.g. tests) incompatibilities later.
Fix was inspired by commit cda0ef61d373 ("python3: fix do_configure
check platform triplet error").
(From OE-Core rev: b2ec91e12088afa0560aecede587d0970fc64110)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running qemu for userspace code on unsupported target binaries might
be bad idea because qemu could say running in endless loop instead
of crashing due to illegal instruction or unsupported binary format.
While this is qemu bug we should avoid hitting it by explicitly exiting
from the wrapper when qemu backfill considered for machine.
Behaviour was observed in do_rootfs stage when building on IBM Power 8
host for PowerPC e7400 target.
(From OE-Core rev: a0ebc77ee0b461fc30e704f7dd9e9c2061ef4193)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bump QEMU to the latest 3.1 and update the patches.
(From OE-Core rev: eeb918fc9b67a5d252b9d5ad5f3674cc1a45aa7f)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a test fails the log has useful information, so include that in the output.
(From OE-Core rev: f66f533eb9974cdefaacfee00d019c65e0d80b9e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The crosssdk dependencies are handled using the virtual/ namespace so
this name doesn't matter in the general sense. We want to be able to provide
recipe maintainer information through overrides though, so this standardises it
with the behaviour from gcc-crosssdk and ensures the maintainer overrides work.
(From OE-Core rev: da8c3728bf8bb4d4ae71e15626fc10976802185d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating a new python2 manifest, there is a corner case on which
the filepath for a certain dependency that was found, could contain
the path of an existing folder, e.g. ${libdir}/python2.7/xmlrpclib.py
module path contains ${libdir}/python2.7/xml, this causes an issue where
the dependency doesnt get eventually added on FILES for that module.
This patch checks if the dependency that was found is a directory, if it
is, it checks if it matches one of the existing directories on the
manifest, if it is not, then it checks if the dependency's path (without
the filename) matches one of the directories.
Also some misc indentation fixes.
(From OE-Core rev: a1c1253b44eb2000de55b7fa3836e5cdaa28a508)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating a new python3 manifest, there is a corner case on which
the filepath for a certain dependency that was found, could contain
the path of an existing folder, e.g. ${libdir}/python3/xmlrpclib.py
module path contains ${libdir}/python3/xml, this causes an issue where
the dependency doesnt get eventually added on FILES for that module.
This patch checks if the dependency that was found is a directory, if it
is, it checks if it matches one of the existing directories on the
manifest, if it is not, then it checks if the dependency's path (without
the filename) matches one of the directories.
(From OE-Core rev: 59db12fdf294cfab5c1730337d092a75867658f7)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGE_NO_GCONV is set in libc-package.bbclass if not all of
'libc-charsets libc-locale-code libc-locales' included in
DISTRO_FEATURES. And then no packages glibc-gconv-* glibc-charmap-* and
glibc-localedata-* is created. Update recipes and conf file which depend
on these packages to check required distro features.
(From OE-Core rev: 58446992de0f16a345f1f55b66d0d34d31dc341b)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
autoconf-doc package contains autoconf.info.
This file contains date when this file was created, i.e:
"This manual (31 January 2018) .."
Therefore, two builds done on two different days will show different dates for
otherwise identical files, hence breaking reproducibility.
The date is obtained from mtime of "autoconf.texi", unfortunately we patch this
file and change the mtime as a consequence.
We restore reproducibility by removing the patch modifying "autoconf.texi".
As a consequence certain supplemental information will be not added to the documentation.
In particular: more details on usage, and on workarounds for non-updated projects.
[YOCTO #12524]
(From OE-Core rev: 1eaa918ae3663e3f863c025744a9ced0300b6b78)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
With applying this fix:
"This manual (24 April 2012) .."
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch altered the clean target's behaviour to skip the ipkg-install
directory. However this directory isn't created by opkg, opkg-utils, or the
package_ipk class; and we don't invoke the clean target as we perform
out-of-tree builds.
(From OE-Core rev: 9f8bd475701e5d797d3ffc1ba97647101ba0b9b0)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We stop distutils for *native* Python from rewriting hashbangs when installing
(so installed scripts don't have a hashbang that refers to sysroot paths), but
this isn't needed nor desirable for the *target* Python.
(From OE-Core rev: 52e128619803907c804d42815ea979b1848529c4)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a special library for memcheck tool, where it needs to have the
symbols intact for the stack traces to work on target, current option is
to install valgrind-dbg ( 151 MB uncompressed ) is quite big for some
systems which may not have space to install it all. Leaving it
unstripped adds about 200KB to image which is much better, this alone
gets memcheck working, as an aside we might need same solution for other
tools e.g. helgrind etc. when needed, they also have leading libraries
installed
(From OE-Core rev: 23da8f50b1e0a74777035c9f7b65b81456908f9f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a backported patch to fix big endian compilation.
(From OE-Core rev: 9f5f4b31df01a29fd07ce27efc7534b4ea29a778)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
