| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
