Under some rare circumstances we may end up with GCC segmentation fault.
This was observed with versions of sysmacros.h, which contain macros
with embedded warning messages :
When trying to actually display the warning, we may end up with a segmentation
fault instead. The reason is the actual warning message gets parsed (the text is
unquoted) and words in the message such as "not", "and" etc. are interpreted as
operators CPP_NOT, CPP_AND. When the time comes to display the warning, the code
uses wrong structure to access the "name" corresponding to the operators.
[YOCTO #11738]
(From OE-Core rev: 6f81fe4f3a1177c0049b26a070e43546bc6fe974)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a patch to force a native build for a helper binary
(which is not installed or used outside of the build process).
(From OE-Core rev: 35e3ed68fd25941e3d76e5a063299b1d1cee0e70)
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>
In upstream, the following commit:
e711cafab1
...
commit e711cafab13efc9c1fe6c5cd75826401445eb585
Author: Benjamin Peterson <benjamin@python.org>
Date: Wed Jun 11 16:44:04 2008 +0000
Merged revisions 64104,64117 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
...
(see diff in setup.py)
It assigned libraries for multiprocessing module according
the host_platform, but not pass it to Extension.
In glibc, the following commit caused two definition of
sem_getvalue are different.
https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524
(see diff in nptl/sem_getvalue.c for detail)
`__new_sem_getvalue' is the latest sem_getvalue@@GLIBC_2.1
and `__old_sem_getvalue' is to compat the old version
sem_getvalue@GLIBC_2.0.
If not explicitly link to library pthread (-lpthread), it will
load glibc's sem_getvalue randomly at runtime.
Such as build python on linux x86_64 host and run the python
on linux x86_32 target. If not link library pthread, it caused
multiprocessing bounded semaphore could not work correctly.
...
>>> import multiprocessing
>>> pool_sema = multiprocessing.BoundedSemaphore(value=1)
>>> pool_sema.acquire()
True
>>> pool_sema.release()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: semaphore or lock released too many times
...
And the semaphore issue also caused multiprocessing.Queue().put() hung.
(From OE-Core rev: ca1542cdf6b6437a2f3dcdb33ac5216bf841c04a)
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>
This was needed when we were conflicting with clang-native
but this is solved via append PN to binaries of llvm-native
(From OE-Core rev: 82ea78bd2f03b6ba4d720595d3a3fbd96e0232f9)
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>
When parsing this recipe on an unsupported or non-mappable architecture
an error is generated despite no dependencies on the recipe. E.g.
ERROR: .../llvm_git.bb: cannot map 'microblazeel' to a supported llvm architecture
Instead of generating an error which might confuse users, raise a
SkipRecipe exception similar to other arch-style mapping functions (e.g.
go_map_arch). This avoids showing the error during parse, and prevents
the use of the recipe on unsupported targets. Resulting in an error like
so when trying to build llvm:
ERROR: Nothing PROVIDES 'llvm'
llvm was skipped: Cannot map 'microblazeel' to a supported LLVM architecture
(From OE-Core rev: d796abac982f368aa088a291560b565cc47a2c27)
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>
We have a variable YOCTO_ALTERNATE_EXE_PATH to point to
target sysroot, utilize this in mesa to use native version
of llvm-config to report values from target sysroot.
(From OE-Core rev: 1c4444f7b2f5cbcaaf6f9d21d7b4f86555ed746a)
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>
Alioth always redirects, so we might as well save time by looking in the right
place.
(From OE-Core rev: e681e25fb8fb97a8592df69180d2fd85d136352c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is highlighted when CC is passing flags like -fPIE
which are stripped by libtool when building shared libs
and replaced with -fPIC, this actually results in CC
not matching the CC computed from cmdline created for
compiling and as a result libtool heuristic to compute
tags auotmatically fails.
(From OE-Core rev: 519c34adeb0735f6ff606addd00a7bbe19f4b15c)
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>
Fixes
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/python3-pycairo/1.10.0-r2/recipe-sysroot-native/usr/bin/x86_64-bec-linu
x/x86_64-bec-linux-ld: src/cairomodule.c.1.o: relocation R_X86_64_PC32 against symbol `CairoError' can not be used whe
n making a shared object; recompile with -fPIC
(From OE-Core rev: 058b155a66c5f81573379d258250323c72901ff7)
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>
External compilers will explicitly pass -fPIE -pie flags
unlike internal toolchain which does not use them, so the build
fails with external toolchains because, its passing these
flags to linker when building with -r option and fails to link
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/go/1.8.3-r0/recipe-sysroot-native/usr/bin/x86_64-bec-linux/x86_64-bec-linux-ld: -r and -pie may not be used together
(From OE-Core rev: bb89849b5edb05a953586d190826a67ba87c1c5a)
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>
libtool tries to guess the --tag value based on CC/CXX environment
variables and the compile commandline generated by makefiles. This
heuristics however fails when we construct CC variables in OE
and add security flags to it, especially -fPIE -pie which are added
by external compilers e.g. clang particularly. It fails because
libtool removed PIE flags from compiler cmdline intelligently
if it figures out that its building a library, which means that
the CC variable passed from cmdline does not match with the compiler
cmdline constructed by libtool and we end up with errors like
| arm-bec-linux-musleabi-libtool: compile: unable to infer tagged configuration
| arm-bec-linux-musleabi-libtool: error: specify a tag with '--tag'
This works with internal gcc toolchain because we configure gcc for
PIE when hardening is selected and dont pass -fPIE -pie options explicitly
but this is not an option for clang, and some external gcc toolchains
using older gcc
This patch adds the --tag option to help libtool set correct tags
in packages where it cant get it right via its heuristics
(From OE-Core rev: 0505075ae8d339ba097aebb82b4d0ae62f87c0a9)
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>
Instead of moving aclocal.m4 to acinclude.m4 in a custom do_configure, simply
tell autoreconf not to run aclocal.
(From OE-Core rev: 5cc53ea9347035f96a721ab057a338eded5c5c67)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Invisible Mirror FTP service is currently down, and FTP is horrible, so
switch to the HTTP mirror.
(From OE-Core rev: f31461f8ea11e82dbe14454a1149d9ec2120404d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although 'test' is listed in the python module list
(https://docs.python.org/3/py-modindex.html) it is meant only to be
used 'internally' by folks developing python itself. Per the
documentation:
Note The test package is meant for internal use by Python only. It
is documented for the benefit of the core developers of Python. Any
use of this package outside of Python’s standard library is
discouraged as code mentioned here can change or be removed without
notice between releases of Python.
Per the above it is best not to include this module to discourage
folks who might not head the above warnings. Additionally this module
is one of the largest py modules going, by dropping this unneeded
module from the 'modules' package we can reduce overall image size,
something which is important for many embedded deployments.
The generator scripts as well as the manifests have thus been modified
accordingly, providing a generic mechanism to exclude modules from the
'all modules' package.
(From OE-Core rev: a5bb13a5d7d7a668ca61da6b17884e3b05b95355)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3, with the
autoconf exception in COPYING.EXCEPTION. OE-core currently has
GPL-3.0-with-GCC-exception for this in meta/conf/licenses.conf, so
this is used here despite the deprecation note for that license
identifier in https://spdx.org/licenses/GPL-3.0-with-autoconf-exception.
(From OE-Core rev: 5849391a1854743af26503db603ad578d8d19e25)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on recipe from meta-oe and clang recipe from meta-clang
Needed by mesa
Fixes
[YOCTO #11529]
(From OE-Core rev: 8724ef9c53e7804ead9ba0f019369b0e4daada63)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm is using it, therefore move it from meta-oe
(From OE-Core rev: fc3aef67a95a90e9a485c6b0e93db8cdeab5d3ab)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than requiring each user to handle this individually, handle
addto_recipe_sysroot in the core class. As well as preserving the
sysroot directory, this also ensures the stamp is preserved rather
than rerunning the task every time as currently happens.
(From OE-Core rev: bf8b9858d9ccce27173d13938a83d249294cc473)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3. There is
also the COPYING.EXCEPTION file with the autotools exception, which
gets ignored here in the recipe to keep it simpler.
All of the explicit dependencies seem unnecessary, and RDEPENDS_${PN}
doesn't do anything for native recipes either, so all of that gets
removed.
It also built fine without the m4 and parallel build workarounds.
There's no need to have a separate .inc file.
(From OE-Core rev: 5002004b891895654cbad53555ee46e2ed188630)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having common macros in OE-core that are needed by autotools based
projects makes sense. For example, tpm2.0-tools in meta-measured
depended on meta-oe only because of autoconf-archive.
This is a verbatim copy of the autoconf-archive recipe in
meta-openembedded rev 1cbd1bc1, with just one change: the patch which
disabled the installation of ax_code_coverage.m4 and
ax_check_enable_debug.m4 and the dependency on gnome-common were
removed.
So now autoconf-archive in OE-core provides them. gnome-common in
meta-oe will be changed to not install them and instead depend on
autoconf-archive.
(From OE-Core rev: 40711432b82fc6efb9e40748532ed68a64fbe628)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Put it in goarch.bbclass which all go related recipes inherit.
(From OE-Core rev: 9e899bbc081cb932c1492f6d6802b908d70ef42f)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPM file signing is enabled with --with-imaevm during configuration.
If enabled, the RPM signing tool rpmsign will call libimaevm.so provided
by the recipe ima-evm-utils.
(From OE-Core rev: 9d7797e4374c111f0dff523fd49354bcc33dc2af)
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
Signed-off-by: Jia Zhang <lans.zhang2008@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
FTP is inferiour to HTTP is all respects, so use the HTTP URL for the tarball.
(From OE-Core rev: 6a9e38be6e9dcbeff033944f9a3a18e3838af10d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-setuptools and python3-setuptools need to be
upgraded to latest upstream version.
license checksum is now targeted to be performed over the actual
license text at license file.
These changes were tested using qemux86 with core-image-minimal.
(From OE-Core rev: 6ad635a33b5a49fa51165b6ac7606b27438f5d96)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We get linking errors on some hosts like
| ld -static --warn-multiple-gp --warn-common -T linux-i386/convert.lds -o objdir/linux-i386/convert ob
jdir/linux-i386/head.o objdir/linux-i386/convert_params.o
| objdir/linux-i386/convert_params.o: In function `printf':
| convert_params.c:(.text+0x1fd): undefined reference to `__stack_chk_fail_local'
This is because the build system is defaulting to host linker when building
32bit binaries and it may not have same defaults as OE toolchain and issue
gets highlighted.
fix it by using cross linker for 32bit links when building on x86_64
(From OE-Core rev: 470c8a0fb5f51a626a194c8fd3aabd448b50ebfa)
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>
Due to a bug in calculating adresses of modified program
headers patchelf breaks executables linked by Gold linker
causing them to segfault, e.g.
$ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help
Segmentation fault
This is reproducible only in some cases and only for executables
of ET_DYN type produced by Gold or by ld linked with pie.
This should be solved by fix-adjusting-startPage.patch that
fixes calculation logic.
[YOCTO #11785]
(From OE-Core rev: 4e4c96db4b1d2356b5d071cee6746a96eca20439)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch has been accepted upstream.
Changed patch status Pending -> Accepted.
(From OE-Core rev: 4e9b1e9798e7b12664d4afc611e430a988b6b1ca)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-git needs to be upgraded to latest upstream version.
"git" is added as RDEPENDS.
These changes were tested using qemux86 with core-image-minimal.
(From OE-Core rev: 0b48514d1d26d234c158a4b72087a67d2478362a)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-mako need to be upgraded to latest upstream version.
This change was tested using qemux86 with core-image-minimal
(From OE-Core rev: 1a2bb950b38035b842d120697d076cfdc832fa37)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the kernel's menuconfig target is called while using the esdk or an
esdk-based container, the pkg-config info that is found is not correct.
The pkg-config info is for the target, but we need the eSDK's information
in order to build the host based menuconfig.
The new pkg-config-esdk script checks both that it's in SDK and being
called from the check-lxdialog script in order to limit the scope of when
the pkg-config automagically switches to pkg-config-native.
The pkg-config-esdk is only installed as pkg-config inside the eSDK, which
is why we use the sstate post install script and check for if we are in the
esdk environment using the WITHIN_EXT_SDK
[YOCTO #11155]
(From OE-Core rev: 0954452d151613fa758fbde8ee9469b30d80776b)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When py3 applications are exiting we often see errors similar to the
following:
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fcb56b09400>
Traceback (most recent call last):
File "/usr/lib64/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
After a quick search this was found to be a well reported issue
upstream and had an appropriate fix which is backported here.
(From OE-Core rev: 8aaf09a916a2f66f1a6a79cbddf45390ecefde4f)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
