You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* bazel: align Linux MKL release parity
Align Bazel Linux MKL release output with Make by fixing oneAPI, parameter, threading, ELF metadata, algorithm coverage, and Linux release packaging boundaries.
Validation on onedal-build:
- bazelisk clean
- bazelisk build //:release --backend_config=mkl --release_dpc=false --jobs=8 --verbose_failures
- passed in 327.09s, 3179 actions
Final compare vs Make MKL release:
- release tree: only_make 0, only_bazel 0
- libonedal_core: members 1919/1919, exports 8545/8545, MKL exports 0
- libonedal_thread: members 2/2, exports 319/319, MKL exports 0
- libonedal: exports 3422/3422, MKL exports 0
- libonedal_parameters: members 8/8, exports 71/71, MKL exports 0
- SONAME/DT_NEEDED match for checked libs; RUNPATH absent
Report:
- /home/ubuntu/onedal-mkl-rootcause-20260614-223805/mkl-close-gaps-final-report.txt
* bazel: fix PR parity CI issues
Add missing license headers for new files.
Use Linux release SONAME symlinks in @onedal_release imports so release-dynamic Bazel example tests can resolve libonedal*.so.4 from _solib runfiles while release artifacts stay RUNPATH-free.
Let only the DPC dynamic oneAPI library include DAAL-tagged objects needed by DPC host helpers, without restoring DAAL object leakage to the host libonedal.so.
* bazel: address MKL parity review findings
* bazel: share release metadata checks
* ci: avoid GitHub API in Bazelisk bootstrap
* ci: compare Make and Bazel release artifacts
* ci: restore Bazelisk release metadata lookup
* bazel: hardcode binary ABI version
* ci: fix Bazel and Conda PR checks
* bazel: fix release dynamic linkage
* bazel: align release metadata generation
* bazel: match release config metadata
* bazel: resolve Windows onedal services link
* bazel: embed DAAL objects into Windows onedal.dll
The previous attempt to bring in DAAL symbols on Windows via
`core_embed` + `core_dynamic` host_deps only re-added the services
+ data_management + DLL shim and the onedal_core import library, but
the Windows linker still saw unresolved DAAL classes consumed
object-locally inside onedal.dll: PCA `interface3::BatchParameter`
ctor / `check()`, PCA `BatchKernel<...>::compute(...)`, covariance
`interface1::Batch` ctor / `Input::set` / `Input::~Input`, and zscore
`interface3::Batch` ctor — none of which onedal_core.dll exports.
lld-link emits hundreds of "undefined symbol" errors and fails the
release build with "too many errors emitted".
Linux .so links are tolerant of unresolved externals and resolve
those DAAL symbols at runtime via DT_NEEDED libonedal_core.so.
Windows DLLs must resolve everything at link time.
Restore link-time resolution by selecting "daal" into the host
`lib_tags` on Windows, mirroring the DPC variant. The DAAL-tagged
objects then flow into onedal.dll directly. Drop the now-unneeded
core_embed module and the core_dynamic host_dep, and keep only
services_win_dll_shim (delay-loads the threading entry points the
embedded kernels reference). On Linux the host build keeps
lib_tags=["dal"] so DAAL is not duplicated into libonedal.so.
* bazel: restore MKL link inputs for DPC DLL
* bazel: fix Windows DPC parameters linkage
* bazel: embed MKL into Windows onedal DLL
* bazel: fix Windows host parameters linkage
* bazel: link LR optimizer into Windows parameters DLL
* conda: avoid timestamped TBB staging path
* ci: normalize build date in release compare
* ci: use package-aware oneDAL setup
0 commit comments