linux/meta-intel.git, branch master

intel-oneapi: drop obsolete standalone component recipes

2026-04-29T15:10:40+00:00

Remove the per-component apt-package recipes superseded by the unified intel-oneapi-toolkit_2026.0.0.198.bb recipe, which packages the same components as sub-packages of a single offline installer (intel-oneapi-toolkit-{compiler,runtime,mkl,tbb,dpl,ipp,...}). Consumers should reference the canonical toolkit sub-package names directly. Recipes removed: * intel-oneapi-dpcpp-cpp_2024.0.0-49819.bb * intel-oneapi-dpcpp-cpp-runtime_2024.0.0-49819.bb * intel-oneapi-mkl_2024.0.0-49656.bb * intel-oneapi-ipp_2021.10.0-653.bb * setup-intel-oneapi-env_2023.0.0-25370.bb (and its intel-oneapi-runtime.conf helper) The setup-intel-oneapi-env helper installed a single ld.so.conf.d snippet pointing the dynamic loader at /opt/intel/oneapi/lib (and lib/intel64, lib/ia32, lib/emu). It dates back to the 2023.0 oneAPI layout. The unified toolkit installs libs under per-component directories such as /opt/intel/oneapi/{compiler,mkl, tbb,...}/2026.0/lib, not the flat /opt/intel/oneapi/lib that the conf file targets, so the ld.so.conf entries no longer point at real directories. Loadability of oneAPI binaries on the target is provided by: * setvars.sh / per-component env/vars.sh sourcing (the canonical Intel-supported entry point that every test and example uses) * $ORIGIN-relative RUNPATH baked into the shipped shared objects by the Intel installer * /etc/OpenCL/vendors/intel-cpu.icd written by the unified toolkit recipe's do_install for ICD loader discovery * virtual-opencl-icd / level-zero-loader RDEPENDS on intel-oneapi-toolkit-runtime for the OpenCL / Level Zero loaders The setup-intel-oneapi-env filename version (2023.0.0-25370) was a stale carry-over from when the recipe was first added; nothing in the recipe ever referenced ${PV}. Signed-off-by: Yogesh Tyagi

packagegroup-sdk: switch ICXSDK to intel-oneapi-toolkit sub-packages

2026-04-29T13:51:34+00:00

The 2024.0 standalone recipes provided per-component package names (intel-oneapi-dpcpp-cpp{,-dev}, intel-oneapi-dpcpp-cpp-runtime{,-dev}) that have been replaced in the unified intel-oneapi-toolkit_2026 recipe by the canonical sub-package layout. Update the SDK host and target packagegroup bbappends to reference the new names directly: intel-oneapi-toolkit-compiler - C/C++/SYCL compiler + headers intel-oneapi-toolkit-runtime - shared runtime libraries The toolkit-compiler sub-package already contains the headers and CMake/pkg-config files the prior *-dev sub-packages exposed, so a separate -dev append is no longer needed. Signed-off-by: Yogesh Tyagi

intel-oneapi-toolkit: add unified 2026.0.0.198 recipe

2026-04-29T13:51:34+00:00

Intel oneAPI 2026.0 ships the former Base and HPC toolkits as a single offline self-extracting installer instead of as the per- component apt packages used in the 2021/2024 layout. Add a recipe that consumes intel-oneapi-toolkit-2026.0.0.198_offline.sh via a pseudo-free do_unpack_vendor task and stages /opt/intel/oneapi into the rootfs. The recipe partitions the installed tree into sub-packages along component boundaries: intel-oneapi-toolkit-{compiler,runtime,mkl, tbb,dpl,debugger,ipp,ccl,vtune,common,licensing}. Consumers should reference these canonical sub-package names directly rather than the per-component apt names that the 2021/2024 standalone recipes exposed. The runtime sub-package additionally: * registers /opt/intel/oneapi/compiler/2026.0/lib/libintelocl.so as /etc/OpenCL/vendors/intel-cpu.icd so systems without an Intel GPU expose an Intel OpenCL platform via the standard ICD mechanism; * installs a libxml2.so.2 -> libxml2.so.16 SONAME compat symlink, because the prebuilt libcommon_clang.so / libintelocl.so are linked against the libxml2 2.x SONAME while current oe-core ships libxml2 3.x as libxml2.so.16. libxml2 3.x is API-compatible with the option-parsing surface the binaries use. The bundle is x86_64-only so COMPATIBLE_HOST is restricted. Signed-off-by: Yogesh Tyagi

classes: add oneapi-vendor-compat bbclass

2026-04-29T13:15:11+00:00

The Intel oneAPI DPC++/C++ compiler binaries (icx, icpx) shipped by meta-intel as prebuilt installers have a fixed default -target triple baked into the LLVM driver. As of the 2025.3.x bundle the triple is 'x86_64-unknown-linux-gnu' (LLVM's portable default); prior 2024.x bundles used 'x86_64-oe-linux' (matching the OpenEmbedded nodistro default of TARGET_VENDOR=oe). icx also emits 'x86_64-linux-gnu' (the Debian/Ubuntu host triple) in some search paths. Yocto distros set TARGET_VENDOR differently: poky uses 'poky' (TARGET_SYS=x86_64-poky-linux), nodistro uses 'oe', etc. The result is a vendor-triple mismatch: icx looks for crtbeginS.o / bits/c++config.h and similar files under one triple while they are installed at another. Until Intel either ships per-vendor variants or the meta-intel oneAPI recipes patch the prebuilt binaries, install a set of compatibility symlinks at rootfs time so every spelling of the multilib vendor triple resolves to the same files on the image. The alias set is configurable via ONEAPI_VENDOR_TRIPLE_ALIASES; entries that already match the native target triple are skipped, so the class is a no-op on images whose native vendor matches every alias. Usage: add to IMAGE_CLASSES in a distro / local config that consumes the Intel oneAPI compiler: IMAGE_CLASSES += "oneapi-vendor-compat" Signed-off-by: Yogesh Tyagi

ispc: isolate LLVM superbuild from recipe-sysroot-native

2026-04-08T17:31:41+00:00

The ISPC superbuild internally builds LLVM (stage1/stage2). The generated toolchain files inherit Yocto flags and sysroot paths, causing CMake to locate libraries from recipe-sysroot-native. This leads to linking failures when host compiler toolchains are used together with libraries built against a newer glibc, resulting in errors such as: undefined reference to `__isoc23_wcstol@GLIBC_2.38' Fix this by isolating the LLVM superbuild from Yocto sysroot: * Patch generated stage1/stage2 toolchain files: - Replace symbolic compiler names (cc/c++) with ${BUILD_CC}/${BUILD_CXX} - Clear injected CMake compiler and linker flags * Prevent CMake from searching recipe-sysroot-native: - Set CMAKE_FIND_ROOT_PATH_MODE_* to NEVER * Disable optional LLVM features requiring external libraries (libedit, terminfo, zstd, zlib) * Scope environment cleanup to the cmake build invocation to avoid leaking Yocto flags into the superbuild This ensures the internal LLVM build uses a consistent host environment, avoiding GLIBC ABI mismatches. Remove ncurses dependency as terminfo/libedit are disabled. Signed-off-by: Yogesh Tyagi

meta-intel/wic: Move to files/wic

2026-04-08T17:29:17+00:00

To align with the new search paths, move the files to the new location. Signed-off-by: Yogesh Tyagi

perf: drop libbpf const qualifier workaround

2026-03-20T13:06:09+00:00

Remove the bbappend that applied const qualifier fixes to libbpf.c. The workaround was required for older kernel versions where building perf with -Werror triggered warnings due to discarded const qualifiers from strstr() and strchr(). The issue is resolved in the currently used linux-intel 6.18 kernel, making this workaround no longer necessary. Signed-off-by: Yogesh Tyagi

layer.conf: Add the new release layer series

2026-03-19T10:58:28+00:00

Add the wrynose release as being compatible with the layer. Signed-off-by: Yogesh Tyagi

meta-intel.inc: set PREFERRED_VERSION for linux-intel to 6.18

2026-03-17T16:33:25+00:00

Update default kernel version preference to 6.18 for both RT and Non RT variants. 6.18 continues to use a single branch for both RT and non-RT kernels. Signed-off-by: Yogesh Tyagi

linux-intel-rt: upgrade 6.12.61 -> 6.18.15

2026-03-17T16:33:14+00:00

Upgrade to Intel LTS RT kernel 6.18.15. Uses same refreshed patches as linux-intel. Release Notes: https://github.com/intel/linux-intel-lts/releases/tag/lts-v6.18.15-linux-260310T050801Z Signed-off-by: Yogesh Tyagi