Refresh avoid-check-user-break-cc.patch to fix fuzz warning.
(From OE-Core rev: 6d9ab12ac113f0f33289200ca3c9df24d9fc1cc2)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove existing files before overwriting them
Archive should extract only the latest same-named entry.
Extracted regular file should not be writtent into existing block
device (or any other one).
https://rt.cpan.org/Ticket/Display.html?id=125523
Affects perl <= 5.26.2
(From OE-Core rev: 037b205e89ae4c7d638a5c15d64f60e16facbaa2)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using += with an over-ride can be a source of confusion so try to
avoid the construct in core recipes.
(From OE-Core rev: 2588c2aae11b7b480022dc11575295fdc792bf3f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perl distribution "XML-Parser" relies for configuration
on the tooling of Devel::CheckLib - which is not aware of
sysroot locations nor of reasonable compiler/link definitions
from outside.
This causes
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA Issue: package libxml-parser-perl contains bad RPATH ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
package libxml-parser-perl contains bad RPATH ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so [rpaths]
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: Function failed: do_package_qa
It's strongly encouraged to the maintainer @toddr to rework the
toolchain for up to date environments.
[RP: Added fix for nativesdk RPATH issues too]
(From OE-Core rev: b103bb9426c0e5e3ef0fe0c34274ad3a06af8b6a)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our eSDK is expected to provide traditional SDK's functionality. But
for cmake, it could not function well in eSDK.
This problem is discovered by the assimp.py test case. The error message
is as below.
testsdkext/tmp/sysroots/x86_64/usr/lib/libz.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
The problem is about cmake-native being unable to find the correct lib.
nativesdk-cmake has solved this problem. So make use of the solution to
solve the eSDK problem.
(From OE-Core rev: c0561e930e688890eb5feb4521b2de196137227a)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since `6146b8c glibc: Disable crypt support in glibc' in oe-core,
python2/3 could not find symbol crypt which caused import crypt failed.
[snip]
>>> import crypt
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.5/crypt.py", line 3, in <module>
import _crypt
ImportError: /usr/lib64/python3.5/lib-dynload/_crypt.cpython-35m-x86_64-linux-gnu.so: undefined symbol: crypt
[snip]
Add virtual/crypt to DEPENDS, and python's build system (setup.py)
will search libcrypt.so in recipe-sysroot and add `-lcrypt' if it
exists.
(From OE-Core rev: d2a929d932900f753af1a06a8cb98d953369e3b4)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LLVM_TARGETS_TO_BUILD is needed to represent HOST_ARCH for
builds and target specific additions should use class-target
override
(From OE-Core rev: 5e6e08512e130951e66376ea43e4e6a98941b950)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use CPPFLAGS instead of CFLAGS since there is C++ compiler being used for somefiles
Fixes
gdb/gdbserver/../../../gdb-8.1.1/gdb/gdbserver/../common/common-utils.c:419: undefined reference to `rpl_stat'
| collect2: error: ld returned 1 exit status
| make[4]: *** [Makefile:414: libinproctrace.so] Error 1
(From OE-Core rev: d6806b449ba8b44fd74dfb05c65b9233b6f3ace5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test in SDK was failing to execute:
$ autoreconf --install --force
due to missing perl modules. Add the needed perl modules
for target build:
perl-module-bytes
perl-module-thread-queue
perl-module-threads
Duplicate the perl module dependencies for SDK as well.
Now autoreconf runs with a trivial example.
(From OE-Core rev: 71764105510e2a98150f63aae0ada1600ad33041)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: Update checksum for copyright year changes
Update to the latest stable version
(From OE-Core rev: 30d0e8e895813bc422d60bd00076a7f16035feeb)
Signed-off-by: Derek Straka <derek@asterius.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm-config is a tool on similar veins as pkg-config but provides a lot
more information and packages which use llvm e.g. mesa use this tool to
poke for llvm related informaiton e.g. version, libpath, includepaths
to name a few, this has few challanges in cross build environments where
llvm-config is supposed to be build for buildhost but provide information
about target llvm which is addressed by building native llvm-config along
with target llvm build, but this is frowned upon by OE build system since
it detects that host paths are being used so we have to build it as part
of llvm-native but then it means install paths for llvm and llvm-native
are different and wrong paths get reported when llvm-config is used.
This is solved by providing YOCTO_ALTERNATE_EXE_PATH variable to let
llvm-config use that path instead of self-relative path to report back
Second problem is when building multi-lib packages base_libdir is different
for target packages but native llvm-config does not know about it so
it reports non-multilibbed paths as libdir and packages can not find
llvm in sysroot. This is fixed by adding another environment variable
YOCTO_ALTERNATE_MULTILIB_NAME which can be set from recipes to set
proper multilib path
(From OE-Core rev: 865eb1c1400e60d09c8f413504123fdfc116a71b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If not defined, llvm build system tries to build one
which then confuses the OE QA system since its building
native tool and target packages in same package build
moreover it is not required since we already have it via
llvm-native
Fixes
ERROR: llvm-6.0-r0 do_package_qa: QA Issue: llvm: The compile log indicates that host include and/or library paths were used.
(From OE-Core rev: 7153a17166d9a94fd0ddc36d597a0140979d58ff)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refresh the following patch:
"disable-graphviz.patch" to fix this warning:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.htmlhttps://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
checking file configure.ac
checking file libvaladoc/Makefile.am
checking file libvaladoc/html/basicdoclet.vala
checking file libvaladoc/html/htmlmarkupwriter.vala
Hunk #1 succeeded at 51 with fuzz 1 (offset 8 lines).
(From OE-Core rev: dfbbff39cfd413510abbd60930232a9c6b35d765)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable profile guided optimization (pgo) for python3. Enabling pgo in
python is generally as simple as invoking the target profile-opt which:
- builds python binaries with profile instrumentation enabled,
- runs a specific profile task using that python to get the profile
data and,
- feeds the compiler with this profile data and rebuilds python.
This change invokes qemu-user for the second step of running a profile
task using target python. Depending on how long profile task takes to
run, this might add a significant time to compilation (which would be
true for native builds too). The default profile task can be changed by
the users depending on what makes sense for their use case (or can be
left empty). In case qemu-user isn't supported, profile task won't be run.
(From OE-Core rev: 05a2a53f9cc7e75b4a3838ab9368cadf0f15ba1b)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #12791]
The one which actually saves the data is data_list.data.d.d_buf, so check it
before free rawdata_base.
This can fix a segmentation fault when prelink libqb_1.0.3:
prelink: /usr/lib/libqb.so.0.18.2: Symbol section index outside of section numbers
The segmentation fault happens when prelink call elf_end().
Fixed:
MACHINE="qemux86-64"
IMAGE_INSTALL_append = " libqb" #libqp is from meta-openembedded
$ bitbake core-image-minimal
Segmention fault
(From OE-Core rev: 560154e8525dce4beb8199ffc0d7c964da9d665a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #12791]
According to struct elf32_hd, the e_shnum is section header number, and the
index is e_shstrndx, not e_shnum.
This can fix segmention fault when handle libqb.so.0.18.2 from libqb_1.0.3.
It fails to handle libqb.so.0.18.2 and get errors:
Symbol section index outside of section numbers
Then segmentation fault, this is because the e_shnum is 34, while e_shstrndx is
27 (it would be 33 when no errors), I've checked several elf files to confirm
that the ones after e_shstrndx is NULL, so use e_shstrndx should be correct.
Fixed:
MACHINE="qemux86-64"
IMAGE_INSTALL_append = " libqb" #libqp is from meta-openembedded
$ bitbake core-image-minimal
Segmention fault
(From OE-Core rev: b7c291ee6532cba845ee6bfbbaa21076a2b2cbe5)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the assembler reports that the input and output are the same, report the
file names involved, in order to help debugging. Also do not equate two files
are the same if the have the same inode value but reside on different file
systems.
(From OE-Core rev: 83cb0938b90bab9ba727f883b8955b0b40d49a01)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We got an error when building setools in meta-selinux:
setools/policyrep/qpol_wrap.c:1819:23:
error: cast between incompatible function types from 'PyObject * (*)(PyObject *)'
{aka 'struct _object * (*)(struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)'
{aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Werror=cast-function-type]
{(char *)"disown", (PyCFunction)SwigPyObject_disown, METH_NOARGS, (char *)"releases ownership of the pointer"},
This is a swig issue. See: https://github.com/swig/swig/issues/1259
Backport a patch from upstream to fix it.
(From OE-Core rev: f0f8ee668de34ad30ca16f5300966a3470018940)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it more suitable to work with, e.g., devtool. It also
prepares for the update to 0.47.0 when the first patch will no longer be
needed (as it is a backport).
(From OE-Core rev: e1297f9a951b1dbafd0e211be63b348f06b1f3cd)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* I'm not using glide, so I'm not going to fix it proplerly,
it was just bothering me in world builds
* this is reproducible only with ptest in DISTRO_FEATUREs (for aarch64
issue) and included security_flags.inc, more specifically with the PIE
flags, so alternative work around is:
SECURITY_CFLAGS_pn-glide = "${SECURITY_NOPIE_CFLAGS}"
(From OE-Core rev: a6295bc505df635ab3b66100d4ee7567c49f907e)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* I'm not using go or go-dep, so I'm not going to fix it proplerly,
it was just bothering me in world builds
* this is reproducible only with ptest in DISTRO_FEATUREs (for aarch64
issue) and included security_flags.inc, more specifically with the PIE
flags, so alternative work around is:
SECURITY_CFLAGS_pn-go = "${SECURITY_NOPIE_CFLAGS}"
SECURITY_CFLAGS_pn-go-dep = "${SECURITY_NOPIE_CFLAGS}"
(From OE-Core rev: b689c72ad2dc84b8bb55ecbf72d95701707b9bb3)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On a system without ccache, f you:
INHERIT += "ccache"
bitbake libtool-cross
<remove INHERIT>
bitbake apmd
then it fails due to being unable to find ccache. The references to ccache are
coded into libtool-cross but the sstate checksum doesn't reflect this due to the
way the class is coded (output should be the same regardless).
The simplest solution is to remove references to ccache from the libtool script.
The output then works regardless of whether ccache is present or not. The
libtool-cross script is only used in a handful of cases (most of the time its
dynamically generated by autoconf) so any performance issue is minor.
(From OE-Core rev: ed550a49d2114c56e5bc033ecd0e83073d2d4067)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting CMAKE_SYSROOT in the toolchain file allows CMake to correctly
remove user-provided system include directories pointing to
<sysroot>/usr/include. The mentioned projects failed with "stdlib.h:
No such file or directory #include_next <stdlib.h>".
(From OE-Core rev: cb42802f2fe1760f894a435b07286bca3a220364)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Raphael Freudiger <raphael.freudiger@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add x86_64-pep emulation support to the set enabled for x86_64 targets
to enable the linker to produce Portable Executables for EFI binaries.
Enables building the x86-64 EFI variant of the Xen hypervisor for
the OpenXT Project.
(From OE-Core rev: 3d493838f0284948a09693ad65656cb7afbb21cc)
Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Distros which have glibc 2.28 on them otherwsise fail
to build due to some syscall mismatches
(From OE-Core rev: 990a9c944375146bb3f0208b30e8b7f50239cef5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has several fixes to get it building with glibc 2.28+
remove backported patch which is not needed now
(From OE-Core rev: f1dc6b5eebf455c46036e200c1eaff34ebd50db1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also fix the license, as this is GPLv2+ not just v2.
(From OE-Core rev: c372bb230640e76af13795433adc76f506e12cc6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake, in it's infinite wisdom, when searching for libraries (using
find_library) will look inside the libraries PREFIX/lib, PREFIX/lib32, and
PREFIX/lib64. In a multilib SDK more than one of these will exist (potentially
all three) and obviously for a given build configuration only one of those is
valid. This search path is hard-coded deep inside CMake but by setting
CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX we can bypass it and set an explicit
lib<SUFFIX> to use.
Do this by writing ${baselib} into the environment file, and then stripping
"lib" from this to obtain the suffix in the cmake-specific environment script,
which is then read in the CMake toolchain.
(From OE-Core rev: 47160a8c51310f2b40cabf4c1910b5df6e0a15d6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
