Repository navigation
Conversation
PyPI's scikit-learn-intelex wheel is Apache-2.0 and links only against the daal (oneDAL) libraries at runtime (Requires-Dist: daal==<version>, no dpctl, no SYCL/MKL NEEDED entries in its own .so files). Its setup.py already degrades to a plain arch-name DALROOT subdirectory and has CPU-only (NO_DPC, NO_DIST) build switches; upstream's own docs state it builds from source on ARM and RISC-V. This builds oneDAL from source once per version (same recipe as the daal port) and reuses it across the interpreter matrix to compile daal4py/_onedal_py_host, instead of waiting on Intel's x86_64-only wheel or a closed MKL/SYCL backend.
luhenry
added a commit
that referenced
this pull request
Oct 13, 2026
luhenry
marked this pull request as draft
October 13, 2026 09:26
Contributor
|
…R lookup The oneTBB build step installed into lib64 (GNUInstallDirs' default on the Rocky 10-based manylinux_riscv64 image, known gotcha 377), but oneDAL's makefile hardcodes TBBDIR.libia.prefix := $(TBBROOT)/lib with no lib64 fallback when given --tbb-dir, so .ci/scripts/build.sh failed with "Can`t find TBB runtimes nether in /work/tbb-install/lib...". Passing -DCMAKE_INSTALL_LIBDIR=lib to the oneTBB cmake configure matches what oneDAL's build expects.
Member
Author
CI failure:
|
…ld's bash -c quoting The oneTBB comment added in the previous commit contained "oneDAL's", whose apostrophe closed the single-quoted docker run bash -c script early. The container only ran up to the oneTBB clone, and the rest of the script then ran on the runner host, where cmake failed with "The source directory /work/tbb-src does not exist". Reword the comment without quotes.
…hosts The oneDAL build failed in the release step, before compiling anything: dev/make/identify_os.sh only maps x86_64 and aarch64, so on the native riscv64 runner it prints "Unknown architecture: riscv64", and the _release_nuspec target that every daal/onedal_c release depends on runs deploy/nuget/prepare_dal_nuget.sh, which exits with "Unknown platform Unknown architecture: riscv64". Upstream never hits this because its riscv64 CI cross-compiles from x86_64. Carry a patch that makes identify_os.sh print lnxriscv64 on riscv64 and gives prepare_dal_nuget.sh a matching lnxriscv64 branch, and apply it in the build_onedal job before the container build. The patch also makes the makefile treat the build as native (PLAT == IDENTIFIED_PLAT), so clang no longer gets --target=riscv64-linux-gnu. That matters on Rocky 10: its GCC lives under riscv64-redhat-linux, which clang does not search for a riscv64-linux-gnu target, so the cross-mode flags would have lost the libstdc++ headers at the compile step that comes next.
…arning
The build_onedal job failed in the Build oneDAL (riscv64) check: the very
first clang++ invocations (cpp/daal/src/services/*.cpp) errored with:
clang++: error: argument unused during compilation:
'--gcc-toolchain=/usr' [-Werror,-Wunused-command-line-argument]
dev/make/common.mk derives --gcc-toolchain from `which gcc` and passes it
to every clang compile, and clang.ref.riscv64.mk's COMPILER.lnx.clang
turns -Werror on. On this riscv64 manylinux image, clang's
GCCInstallation probe does not treat that hint as applicable to every
translation unit (at least the services/*.cpp ones, which pull in no
libstdc++ headers), so the otherwise-harmless "unused argument" notice
becomes a hard build failure. The same --gcc-toolchain mechanism runs
unconditionally for every clang platform (x86_64, arm, ...); only
riscv64 hits this, consistent with clang's RISC-V GCCInstallation
detection being newer/less-trodden than the other architectures'.
Carry a second patch adding -Wno-unused-command-line-argument next to
the existing -Werror, so this one diagnostic stays non-fatal without
changing which headers/libraries get searched or used.
PR #2971 (daal) builds oneDAL the same way and hits the identical
failure; this only fixes this port's own copy of the recipe.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
scikit-learn-intelex2026.1.0Compiles daal4py and the onedal pybind11/CMake module against a from-source oneDAL (CPU-only
hostiface, NO_DIST/NO_DPC). Upstream publishes no riscv64 wheel.No equivalent upstream workflow builds this exact wheel; mirrors
doc/building-from-source.rst's documented from-source recipe, which upstream states already covers ARM and RISC-V.Differs from upstream
daalport's workflow) instead of consuming Intel's x86_64-onlydaal/daal-develwheel.clang+clang-tools-extrafrom the image instead of theclang-formatPyPI package, which ships no riscv64 binary.Matrix: cp310-cp314 (no cp314t), matching upstream's own released interpreter set.
Testing
daal4py,onedal,sklearnexand callspatch_sklearn()instead of upstream's full pytest suite (GPU/distributed-only fixtures aside, this mirrorsci.yml's own smoke import).License: Nothing third-party vendored; the wheel links oneDAL (separately licensed Apache-2.0) at runtime only.
Depends on the
daalport (#2971) landing first for the runtimeRequires-Distpin to resolve; builds and tests independently since oneDAL is built from source in this workflow too.