Repository navigation
Conversation
PyPI's daal wheel is Intel's own prebuilt x86_64/win_amd64-only binary
under the Intel Simplified Software License with no sdist, and
statically bakes in closed oneMKL kernels. oneDAL itself is Apache-2.0
and ships a real non-x86 "ref" backend (RISCV64 CpuType, dedicated
dev/make/function_definitions/{riscv64,lnxriscv64}.mk and
clang.ref.riscv64.mk, an exercised upstream Azure Pipelines rv64 job)
with no SIMD/MKL dependency, built here against OpenBLAS (statically
linked, NO_FORTRAN=1) and oneTBB (dynamically linked, satisfied at
install time by this registry's existing tbb==2023.* port) instead.
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
|
The riscv64 CI job failed with "Can't find TBB runtimes nether in /work/tbb-install/lib not in ...": oneTBB's CMake build installs under GNUInstallDirs' CMAKE_INSTALL_LIBDIR, which defaults to lib64 on the Rocky-based manylinux_2_39_riscv64 image (gotcha 377), while oneDAL's makefile hardcodes TBBDIR.libia.prefix to "$TBBROOT/lib". Pinning -DCMAKE_INSTALL_LIBDIR=lib on the oneTBB configure matches OpenBLAS's own install layout and what oneDAL's build looks for.
Member
Author
|
CI root-caused and fixed. What failed: Root cause: the oneTBB build step configures with plain CMake and no Fix: pin |
The oneTBB step failed with "fatal: could not create leading
directories of '/work/tbb-src': Permission denied". The comment added
in the previous commit sits inside the single-quoted `bash -c '...'`
script passed to docker run, and its apostrophe ("oneDAL's") closed
that quote early. The container script therefore ended right after the
OpenBLAS build, and the runner's own shell ran the oneTBB `git clone`
on the host, where /work does not exist. Reword the comment without
apostrophes so the whole script is passed to the container again.
The build failed in the release step of `make daal`, 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 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 before the container build. It also makes the makefile treat the build as native (PLAT == IDENTIFIED_PLAT), so clang no longer gets --target=riscv64-linux-gnu. Also pass packages=[] to the generated setup.py: without it setuptools auto-discovery runs in the oneDAL checkout root and stops with "Multiple top-level packages discovered in a flat-layout: ['dev', 'cpp', 'data', 'cmake', 'deploy', 'samples', 'dist_libs']".
The build got past the identify_os.sh fix and into the real compile
step, then failed on every core_static translation unit:
clang++: error: argument unused during compilation:
'--gcc-toolchain=/usr' [-Werror,-Wunused-command-line-argument]
make: *** [makefile:567: .../daal_strings.o] Error 1
oneDAL's top-level makefile always appends
`--gcc-toolchain=$(GCC_TOOLCHAIN_PATH)` to every compile invocation
(dev/make/common.mk), with GCC_TOOLCHAIN_PATH derived from `which gcc`
(/usr in the manylinux_riscv64 image). Now that the host is treated as
native rather than cross (previous commit), clang.ref.riscv64.mk no
longer adds a `--target=` flag, and clang's riscv64 driver never
consults the GCC installation during the compile-only (-c) step the
flag is passed on, so it flags the argument as unused; COMPILER.lnx.clang
pairs that with -Werror, turning it into a hard failure.
Carry a patch adding -Wno-unused-command-line-argument next to
-Werror in clang.ref.riscv64.mk, mirroring how icx.mkl.32e.mk already
silences the identical situation for its own -static-libstdc++ flag
(also unused at compile time, needed at link time), rather than
dropping -Werror or the toolchain flag.
luhenry
added a commit
that referenced
this pull request
Oct 25, 2026
…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.
daal2026.1.0Compiles oneDAL's
daal+onedal_clibraries against OpenBLAS and oneTBB using its own "ref" CPU-dispatch backend (no SIMD/MKL). Upstream publishes no riscv64 wheel.Mirrors oneDAL's own riscv64 Azure Pipelines job (
LinuxMakeLLVM_OpenBLAS_rv64in.ci/pipeline/ci.yml).Differs from upstream
Testing
.sowithctypesinstead of upstream's QEMU-run C++ examples (no Python bindings in this wheel).License: Statically links OpenBLAS (BSD-3-Clause); its LICENSE ships alongside oneDAL's Apache-2.0 one.
Built on cp312 (library-only wheel, no interpreter matrix).