Note that to actually use accelerated GL passthrough, there are two options
1) a suitable frontend need to be also enabled - gtk+ and SDL both seem to work well.
Previously I struggled to make SDL work, but now it seems fine.
2) it is also possible to render off-screen with -display egl-headless option,
and see the output with a VNC viewer (for which, qemu needs to be started
with a VNC server):
$ runqemu kvm egl-headless publicvnc
(From OE-Core rev: 662c688e635f4490aac0d6d34ce7a7b31d73f5c5)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are issues with multilib due to the ordering of events where some
functions see the remapped multilib dependencies and some do not. A significant
problem is that the multilib class needs to make some changes before key expansion
and some afterwards but by using existing event handlers, some code sees things
in a partially translated state, leading to bugs.
This patch changes things to use a new event handler from bitbake which makes the
ordering of the changes explcit.
The challenge in doing this is that it breaks some existing anonymous python and
dyanmic assignments. In some cases these used to be translated and no longer are,
meaning MLPREFIX has to be added. In some cases these are now translated and the
MLPREFIX can be removed.
This change does now make it very clear when MLPREFIX is required and when it is
not, its just the migration path which is harder. The patch changes the small number
of cases where fixes are needed.
In particular, where a variable like RDEPENDS is conditionally extended (e.g.
with an override), MLPREFIX is now required.
This patch also reverts:
base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION'
This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
to multilib datastore handling mean its no longer necessary.
(From OE-Core rev: b3fda056a674889cd9697e779de023d4f993d3ce)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
dep utility must not use 'go mod' support, so we explicitly disable it.
(From OE-Core rev: b34000ae3dd6e0a1d7fc332efb35c5da84cf2275)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Glide utility must not use 'go mod' support, so we explicitly disable
it.
(From OE-Core rev: b5a4369ba606677285b0a89a78c040b38f57767f)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
file-native when built on a Debian 10 host will embed a dependency to
'libbz2.so.1.0' (instead of 'libbz2.so.1'). This can cause issues
when sharing the sstate between hosts e.g.:
recipe-sysroot-native/usr/lib/rpm/rpmdeps:
error while loading shared libraries: libbz2.so.1.0: \
cannot open shared object file: No such file or directory
To avoid this situation, let's add the bzip2-replacement-native to the
file recipe's DEPENDS_class-native .
Details in https://bugzilla.yoctoproject.org/show_bug.cgi?id=13915 .
(From OE-Core rev: 4a996574464028bd5d57b90920d0887d1a81e9e9)
Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mudflap was removed in gcc 4.9.
(From OE-Core rev: 6d649a07cfa0a89448caa67e4ca0a990973961b9)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop disabling outline-atomics since that was added to fix this issue in
particular
(From OE-Core rev: 702a1ae29c6a0f920bd67b7a7a41b886ac52a751)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bring in a patch from fedora to fix -fno-common issue
(From OE-Core rev: f635bd89d53cc8c110b18aa593babc55eeffc511)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also splits apart the SRC_URI checksums to make automatic upgrades
easier
(From OE-Core rev: ae1f210546396b761ea86d9e32bf90c0867ff845)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Imports the pyelftools recipes from meta-python, as of 7c02c7d41
("gnome-themes-extra: correct the recipe name").
This recipe is commonly used by other layers, so moving it into
OE-core helps to cut down on layer dependencies.
(From OE-Core rev: 910ffaf5beed42936588c95b0c7c1b1ad67f99d3)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Imports the pycryptodome recipes from meta-python, as of 7c02c7d41
("gnome-themes-extra: correct the recipe name").
These recipes are commonly used by other layers, so moving them into
OE-core helps to cut down on layer dependencies.
(From OE-Core rev: a96f815c53364b119b5743b8b7100eb5588d5cf5)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issue has been fixed in valgrind itself
(From OE-Core rev: c4070f3d76e0170cf6ee672a8a9a38e4cdbbcad9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the __getauxval undefined reference error seen with gcc10 on
doing static linking with -nodefaultlibs, which is uncommon usecase
anyway, disabling outline-atomics is not a huge deal for OE in terms of
performance as we already use -mcpu which is tuned enough to the SOC the
code is being generated for
(From OE-Core rev: 3952738d083b888e5b898ed3d63a0ed9a4dd3712)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Explicitly make the BUILT_SOURCES which
are the generated headers such as stdio.h,
fcntl.h and etc to be the dependencies of
the gl_LIBOBJS such as libbison_a-sprintf.o,
libbison_a-printf.o and etc to guarantee the
BUILT_SOURCES is generated before begin to
compile EXTRA_lib_libbison_a_SOURCES such as
fprintf.c in parallel builid, otherwise there
may come below error:
| muscle-tab.c:(.text+0x77a): undefined reference to `rpl_sprintf'
It does the same for src_bison_OBJECTS and
lib_libbison_a_OBJECTS to make sure BUILT_SOURCES
generated before begin to compile src_bison_SOURCES
which contains AnnotationList.c and etc.
BTW, the MOSTLYCLEANFILES also contains the
generated header needs to be created early
in the build process, so add it also in to
avoid below error:
| ./lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No such file or directory
[YOCTO #13825]
(From OE-Core rev: d4a0cbf132cf6a821e3efe7db3d9afd014cc9bc6)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libatomic has mind of its own when it comes to setting -march for arm64
which conflicts with -mcpu option we pass from environment in some cases
since we always pass -march/-mcpu in OE, its safe to remove this option
mcpu removal from cortex-a55 is no longer needed since the option
conflict is now removed from libatomic instead
(From OE-Core rev: a5331c5a8bbe63c6c2e56ebec496b28968d4663d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to set PACKAGECONFIG_class-native to the same value
as the default PACKAGECONFIG.
(From OE-Core rev: 276a21cbbfc929f718fd758b64e3e0567534fd41)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was added recently, but it seems be chewing more than what it
should and causes non glibc packages also depend on it.
(From OE-Core rev: 595d2df62b049e463568ab97cfe26d6df96a18a9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For time being change back to -fcommon as default, helps us iron
out other issues, eventually this should be removed as we fix the
packages to work with -fno-common
(From OE-Core rev: 951e859b1e8297970278c539e989b8a6d06a9cb3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I cannot reproduce the problem.
(From OE-Core rev: 80cc6e60b98da7c9de9e9da629353cf1fb687197)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A few options of file configure are set to auto, which can lead to
unpredictable effects when something in the sysroot does provide
things that satisfy the autotools checks.
In the worst case this will lead to package-qa failures as libraries are
not set in RDEPENDS but configured for the tool.
To mitigate changes of accidental configure set explicit options via
newly introduced PACKAGECONFIG variables for bzip, lzma and zlib
support, where the default is just zlib, as it was before
(From OE-Core rev: a2236917395239eba7a8358ca4de61fd0d25b27f)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-runtime/libatomic explicitly add -march=armv8-a+lse for all arch64
but cortex-a55 is armv8.2-a, which essentially conflicts, so let gcc
override it by not forcing the -mcpu option from TUNE_CCARGS
(From OE-Core rev: 882df891e13ce5c64718c364efb9ef2bf189eabf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc 10 introduced "-fno-common" as default. Therefore backport the
according binutils patch to fix this issue.
(From OE-Core rev: fbeb572e1872cf64786d01d5c6408a6765f814ce)
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In this update the 0001-Make-__comps_objmrtree_all-static-inline.patch
was mainlined by commit 18f52cb.
Furthermore mainline commit 3237f44 fixes a build problem with the
default "-fno-common" of gcc 10.
(From OE-Core rev: 90b942d01decbcff3b883ee6fb4bba67fb446817)
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'pseudo_access_t' is a type, so use typedef.
Fixes building pseudo with gcc 10 where -fno-common is the default.
(From OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following error occurred when prefer_color set to 2:
Error: Transaction check error:
file /sbin/ldconfig conflicts between attempted installs of
ldconfig-2.31+git0+71f2b249a2-r0.mips64_n32 and
lib32-ldconfig-2.31+git0+71f2b249a2-r0.mips32r2
file /usr/bin/gencat conflicts between attempted installs of
lib32-libc6-utils-2.31+git0+71f2b249a2-r0.mips32r2
...
This was because:
transactions_color = 001 (ELF32) & 010 (ELF64) & 100 (ELF32 N32 MIPS64)
FColor = Current file color (001) & transaction_color (111)
oFcolor = Previous file color (100) & transaction_color (111)
when "neither preferred" happened, handled as conflicts. this is too
restrictive for three way conflicts(mips64/mips64 n32/mips(32)).
Fixed by perform a 'last-in-wins' resolution when "neither is preferred".
refer:
https://github.com/rpm-software-management/rpm/issues/193https://git.openembedded.org/openembedded-core/commit/meta/recipes-devtools/rpm?id=36c225704daa58b98a4b7f2ef315eb944d8628b5
(From OE-Core rev: f94511fe5c163de8fb34d00ff3ba995437c3922c)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
