The installed public header libp11.h includes "p11_ver.h", but that
header is generated by configure (from p11_ver.h.in, via AC_CONFIG_FILES)
and was never listed in include_HEADERS, so it never gets installed.
Any consumer including <libp11.h> therefore fails to build. For example
rng-tools with PACKAGECONFIG "libp11" enabled:
| In file included from rngd_pkcs11.c:28:
| recipe-sysroot/usr/include/libp11.h:28:10: fatal error: p11_ver.h: No such file or directory
| 28 | #include "p11_ver.h"
| | ^~~~~~~~~~~
| compilation terminated.
Backport the upstream fix, which adds p11_ver.h to include_HEADERS. It
landed after the libp11-0.4.19 tag and is not part of any release yet,
so it cannot be picked up by a version upgrade.
Signed-off-by: Daiane Angolini <daiane.angolini@oss.qualcomm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
thirdparty/zstd.cmake compiles the bundled zstd's huf_decompress.c but
not the assembly file it pairs with,
zstd/lib/decompress/huf_decompress_amd64.S. zstd selects the assembly
fast loops in portability_macros.h whenever
!defined(ZSTD_DISABLE_ASM) && ZSTD_ASM_SUPPORTED &&
defined(__x86_64__) && (DYNAMIC_BMI2 || defined(__BMI2__))
so the DYNAMIC_BMI2=0 that apitrace already sets is not enough: any
x86-64 tune whose -march implies BMI2, such as x86-64-v3, still takes
that path and fails to link:
| ld.lld: error: undefined hidden symbol: HUF_decompress4X2_usingDTable_internal_fast_asm_loop
| >>> referenced by huf_decompress.c:1739
| >>> thirdparty/apitrace.lto.libzstd_bundled.a(huf_decompress.c.o)
| ld.lld: error: undefined hidden symbol: HUF_decompress4X1_usingDTable_internal_fast_asm_loop
| >>> referenced by huf_decompress.c:917
Plain -march=x86-64 does not define __BMI2__, which is why only the more
specific tunes are affected.
Define ZSTD_DISABLE_ASM so the C fast loops are used consistently, which
is already what every non-BMI2 build gets.
Not fixed upstream: master carries the same zstd.cmake, no commit since
tag 14.0 touches it, and none of the 19 open pull requests or any issue
covers this.
Verified on x86-64 for qemux86-64 (x86-64-v3 tune): do_compile fails
before the change while linking gltrim and apitrace, and do_compile,
do_install and do_package succeed after.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
configure.in calls AC_PROG_OBJC and libSDL_image_la_SOURCES carries an
Objective-C source, so automake selects Objective-C as the link language
for the library and emits:
libSDL_image_la_LINK = $(LIBTOOL) ... --mode=link $(OBJCLD) \
$(AM_OBJCFLAGS) $(OBJCFLAGS) ...
OBJCLD = $(OBJC)
AC_PROG_OBJC detects a bare compiler carrying none of TOOLCHAIN_OPTIONS,
so while compilation goes through $(CC) and is fine, the link drops
--sysroot and the tune flags and falls over:
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lpng
ld.lld: error: unable to find library -ljpeg
ld.lld: error: unable to find library -ltiff
ld.lld: error: unable to find library -lz
ld.lld: error: unable to find library -lSDL
Export OBJC as CC so the link gets the full toolchain options.
configure.in already forces OBJCFLAGS=$CFLAGS, so that needs nothing.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The 9.1.0 pyproject.toml sets build-backend = "uv_build" and lists only
uv_build in its build-system requires, but the recipe inherited
python_setuptools_build_meta and added python3-uv-build-native to DEPENDS
by hand. Inherit python_uv_build instead, which drops the unused
setuptools, wheel and setuptools-scm dependencies and the setuptools
specific do_configure[cleandirs] workaround that came with the old class.
The patch capped uv_build at <0.12.0, which the 0.11.32 -> 0.12.1
upgrade in oe-core invalidated. This bound has now broken twice, and
there is only ever one uv-build in the sysroot, so drop the upper bound
rather than raise it again.
Verified on aarch64 for qemuarm64: do_compile and do_package succeed.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
bleak's build backend is uv_build, but the recipe inherited
python_poetry_core and then added python3-uv-build-native to DEPENDS by
hand. Both classes are thin wrappers over python_pep517 that differ only
in the native backend they pull in, and python_pep517 takes the backend
from pyproject.toml, so inherit python_uv_build instead and drop the
manual DEPENDS along with the unused poetry-core dependency.
The patch capped uv_build at <0.12.0, which the 0.11.32 -> 0.12.1
upgrade in oe-core invalidated:
ERROR Unmet dependencies (checked against .../nativepython3):
uv_build<0.12.0,>=0.10.9
This bound has now broken twice, and there is only ever one uv-build in
the sysroot, so drop the upper bound rather than raise it again.
Verified on aarch64 for qemuarm64: do_compile fails before the change
with the error above and both do_compile and do_package succeed after.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Inherit ptest-python-pytest and include tests for Pika. Run the
tests that don't require the docker container with RabbitMQ. The
PyPI package omits some files for testing like tests/__init__.py
use the GitHub source for SRC_URI instead.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Add a DESCRIPTION and extend the runtime dependencies of the recipe
for pytest-timeout, a pytest plugin to abort hanging tests.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The Makefile uses `KERN_MAJ = $(shell uname -r | cut -d . -f1)` to
determine if the kernel version is <7, which enables building vboxvideo.
Therefore, with a host kernel >=7 and a target kernel <7, vboxvideo is
not built and we get this error in vboxsf:
```
| In file included from ../vboxsf/include/iprt/stdarg.h:59,
| from ../vboxsf/include/iprt/types.h:44,
| from ../vboxsf/include/iprt/string.h:43,
| from mount.vboxsf.c:62:
| ../vboxsf/include/linux/stdarg.h:6:9: warning: 'va_start' redefined
| 6 | #define va_start(v, l) __builtin_va_start(v, l)
| | ^~~~~~~~
| In file included from mount.vboxsf.c:44:
|
/work/oe-upstream/bitbake-builds/poky-master/build/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/7.2.14/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/16.1.0/include/stdarg.h:49:9:
note: this is the location of the previous definition
| 49 | #define va_start(...) __builtin_c23_va_start(__VA_ARGS__)
| | ^~~~~~~~
| ../vboxsf/include/linux/stdarg.h:8:9: warning: 'va_arg' redefined
| 8 | #define va_arg(v, T) __builtin_va_arg(v, T)
| | ^~~~~~
|
/work/oe-upstream/bitbake-builds/poky-master/build/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/7.2.14/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/16.1.0/include/stdarg.h:54:9:
note: this is the location of the previous definition
| 54 | #define va_arg(v,l) __builtin_va_arg(v,l)
| | ^~~~~~
| ../vboxsf/include/linux/stdarg.h:9:9: warning: 'va_copy' redefined
| 9 | #define va_copy(d, s) __builtin_va_copy(d, s)
| | ^~~~~~~
|
/work/oe-upstream/bitbake-builds/poky-master/build/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/7.2.14/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/16.1.0/include/stdarg.h:57:9:
note: this is the location of the previous definition
| 57 | #define va_copy(d,s) __builtin_va_copy(d,s)
| | ^~~~~~~
```
If the missmatch is reversed, there is probably a different error.
To fix this we provide the actual target kernel version via the KERN_MAJ
Makefile variable
Note: The kernel version might be empty during parsing (e.g. when using
linux-dummy), therefore `or ''` is needed.
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
rav1e's default features include git_version, which pulls built/git2 and thus
libgit2-sys into build.rs -- a *build-dependency*, so it is probed and linked
for the build host. cargo_common exports LIBGIT2_NO_VENDOR, so libgit2-sys
probes pkg-config, which points at the target sysroot, and the host link then
picks up the target's libm.so linker script. That script names absolute
target paths (/usr/lib/libm.so.6), which only resolve on the build host when
host and target architectures differ enough for ld to skip the script as
incompatible, so this breaks on aarch64 hosts building aarch64 targets.
git_version only embeds a git hash in the version string, which is
meaningless here, so drop it and keep the rest of the default feature set.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Daiane Angolini
Khem Raj
Ankur Tyagi
Devansh Patel
Leon Anavi
Rouven Rastetter
Jason Schonberg
Wang Mingyu