| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <yogesh.tyagi@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move intel-oneapi-ipp and setup-intel-oneapi-env recipes under
dynamic-layers/openembedded-layer to make oneAPI components
conditionally enabled.
This is a pure refactor with no functional changes to the recipes.
It aligns oneAPI packages with the existing dynamic layer structure
used for optional Intel runtimes.
Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
|
| |
|
|
|
|
|
|
| |
Yocto 5.3 merged most of meta-clang.
Fix recipes structure in dynamic-layers/clang-layer
clang recipes now depend on meta-clang-revival layer
Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
|
| |
|
|
|
|
|
|
| |
Update to match the recent changes in OE-Core where the unpack layout changed.
[https://patchwork.yoctoproject.org/project/oe-core/patch/20250616095000.2918921-1-alex.kanavin@gmail.com/]
Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
| |
Updated license installation location in licensing/third-party-programs.txt.
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
poky commit b7b382101b401deda2df5e7f71e581d8ced51f5f enabled INHIBIT_DEFAULT_DEPS
in bin_package that removes compiler and C libraries from DEPENDS.
which causes do_package_qa failures:
| libippvm.so.10.6 contained in package intel-oneapi-ipp requires libdl.so.2(GLIBC_2.2.5)(64bit), but no providers found in RDEPENDS:intel-oneapi-ipp? [file-rdeps]
| libippvm.so.10.6 contained in package intel-oneapi-ipp requires libc.so.6(GLIBC_2.3.4)(64bit), but no providers found in RDEPENDS:intel-oneapi-ipp? [file-rdeps]
| libippvmy8.so.10.6 contained in package intel-oneapi-ipp requires libm.so.6()(64bit), but no providers found in RDEPENDS:intel-oneapi-ipp? [file-rdeps]
Disable INHIBIT_DEFAULT_DEPS locally in recipe for now.
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
| |
Required when building applications with ipp.
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
| |
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
The recipe for Intel OneAPI IPP library version 2021.5.1.
IPP is an extensive library of ready-to-use, domain-specific functions
that are highly optimized for diverse Intel architectures.
Signed-off-by: Mariia Vtiurina <mariia.vtiurina@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
The recipe for Intel OneAPI IPP library version 2021.4.0.
IPP is an extensive library of ready-to-use, domain-specific functions
that are highly optimized for diverse Intel architectures.
Signed-off-by: Mariia Vtiurina <mariia.vtiurina@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
|
|
The initial version of the recipe for Intel OneAPI IPP library.
IPP is an extensive library of ready-to-use, domain-specific functions
that are highly optimized for diverse Intel architectures.
Signed-off-by: Mariia Vtiurina <mariia.vtiurina@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
