Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11028656/intel-dpcpp.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11028656/intel-dpcpp-7.1.1-1.fc46.src.rpm Description: DPC++ is a LLVM-based compiler project that implements compiler and runtime support for the SYCL* language. It provides the clang-based compiler driver (installed as dpclang / dpclang++), the SYCL runtime, and the oneAPI Unified Runtime adapters for Level Zero and OpenCL devices. Fedora Account System Username: androniychuk
fedora-review(1) highlights below. - Header files in -devel subpackage, if present. Note: intel-dpcpp : /usr/lib64/dpcpp/lib/clang/22/include/__clang_cuda_builtin_vars.h [...] Here and generally we should probably follow the example of how rocm-compilersupport bundles its llvm. For rocm the Requires chain is hipcc -> rocm-device-libs -> rocm-clang-devel. - Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files directly in %_libdir. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_devel_packages This seems to be complaining about the various collector plugins, libsycl_profiler_collector.so and friends. I suspect these are in %{_libdir} because they're dlopen'd without an explicit path; but, depending where that dlopen call actually is, DT_RUNPATH might already be in the calling object and we could put them in %{_libdir}/dpcpp/lib instead. - Static libraries in -static or -devel subpackage, providing -devel if present. Note: Package has .a files: intel-dpcpp, intel-dpcpp-devel, intel-dpcpp- xptifw-devel. Illegal package name: intel-dpcpp. Does not provide -static: intel-dpcpp. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#packaging-static-libraries This is about %{_libdir}/dpcpp/lib/clang/22/lib/*.a; here again, follow rocm-compilersupport. None of the automated review checks fail. Non-automated checks: ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. Generic: [X]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. [X]: License file installed when any subpackage combination is installed. [X]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [!]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib64/dpcpp/lib, /usr/lib64/dpcpp See the rocm-llvm-filesystem package. [!]: %build honors applicable compiler flags or justifies otherwise. We shouldn't disable debuginfo. This does use a lot of disk space, but most of that is eliminated if you build with -DBUILD_SHARED_LIBS=ON and set an appropriate symbol version string so as not to conflict with LLVM_22.1 or whatever from the base llvm release. [!]: Package contains no bundled libraries or specifies bundled libraries with Provides: bundled(<libname>) if unbundling is not possible. Mostly correct, but rocm-compilersupport has bundled(llvm-project) = %{llvm_maj_ver} so we probably should too. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [!]: Development files must be in a -devel package As above. [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [!]: Useful -debuginfo package or justification otherwise. As above. [!]: Package is not known to require an ExcludeArch tag. Package has ExclusiveArch: x86_64, which is suboptimal. At a minimum we should build this for ppc64le and aarch64 as well... but given that we're not gating the build on passing the self-tests I feel like we should just remove the ExclusiveArch line. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 26656 bytes in 2 files. [x]: Package complies to the Packaging Guidelines ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [!]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in intel- dpcpp-runtime , intel-dpcpp-devel , intel-dpcpp-xptifw , intel-dpcpp- xptifw-devel [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [!]: %check is present and all tests pass. Have not tested whether this passes yet. rocm-compilersupport doesn't seem to run this, but base llvm does... up to you, but if you can tolerate the increased build time I'd recommend it. [x]: Packages should try to preserve timestamps of original installed files. [x]: Spec use %global instead of %define unless justified. Note: %define requiring justification: %define autorelease(e:s:pb:n) %{?-p:0.}%{lua: False positive warning, this is from the system rpm macros and isn't your fault.
@ajax I completed the items above in 1 version of the spec file and the build is successful. This version still keeps the arch to x86_64. How come? dpcpp is heavily based on level-zero and that is ONLY x86_64 https://src.fedoraproject.org/rpms/oneapi-level-zero/blob/rawhide/f/oneapi-level-zero.spec#_13 compute-runtime is ONLY x86_64 https://src.fedoraproject.org/rpms/intel-compute-runtime/blob/rawhide/f/intel-compute-runtime.spec#_22 I think this would be a waste of resources to compile on other arches. These are super long running builds 3 hours+ on copr. checks pass on x86_64 and aarch64, but unit tests fail on the other arches. I honestly don't see anyone installing these packages that does not have Intel GPU's. Your call though, I have another build in copr that will finish in 3 hours with the arches enabled, but checking disabled for everything but x86_64. SPEC URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11087125/intel-dpcpp.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11087125/intel-dpcpp-7.1.1-1.fc46.src.rpm
I think this is the best middle ground for the arch and testing questions SPEC: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11090642/intel-dpcpp.spec SRPM: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11090642/intel-dpcpp-7.1.1-1.fc46.src.rpm Here is a build with multiple archs https://copr.fedorainfracloud.org/coprs/androniychuk/intel-dpcpp/build/11090183/
> dpcpp is heavily based on level-zero and that is ONLY x86_64 The oneapi-level-zero package happens to be ExclusiveArch'd, but as far as I can tell it builds elsewhere just fine. dpcpp also needs the 'intel-level-zero-devel' package, which does come from intel-compute-runtime, which has a slightly stronger case for being x86_64 only. But there do exist PCIe cards bearing Intel GPUs, and idk why they shouldn't work if plugged into an aarch64 machine. In any case, my understanding is that SYCL (well, unified-runtime specifically) should work on any sufficiently capable OpenCL implementation, and we do build Mesa's OpenCL support on every architecture. Disabling the L0 backend in u-r on non-x86 might be a compromise? My real concern is as we start moving up the UXL stack. oneDNN prefers to be built with DPCPP and explicitly supports aarch64, for example. It would be strongly preferable if it built with the same compiler on all architectures, so that as far as possible it behaves the same way on every platform. (I can't find a good citation for this in the Fedora Packaging Guidelines, but they do say "make every effort to support all primary architectures" which is x86_64 and aarch64 at the moment). The only example I can readily find of a package explicitly choosing a different compiler per-architecture is some versions of ghc, where it seems to be a workaround for ppc64le and doesn't otherwise affect the feature set.
Fair enough, I added aarch64 support and pushed latest spec/srpm to copr https://copr.fedorainfracloud.org/coprs/androniychuk/intel-dpcpp/build/11095115/ Should pass, as it passed locally and I will update bug once this is complete
SPEC URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11095115/intel-dpcpp.spec SPRM URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11095115/intel-dpcpp-7.1.1-1.fc46.src.rpm
Pytorch build expects that dpclang compiler will provide package config file with the name sycl-dpcpp-{major}.pc [1], where {major} is a major version of the compiler. At the moment this does not hold true for the proposed fedora packaging: # find /usr/lib64/pkgconfig/ -name "sycl*" /usr/lib64/pkgconfig/sycl-dpcpp.pc Can package, please, install sycl-dpcpp-7.pc as that's an existing contract between dpclang compiler and projects which use it (pytorch). [1] https://github.com/pytorch/pytorch/blob/15b2f95995d9d48d146f1ebd1712328a78c00901/cmake/Modules/FindSYCLToolkit.cmake#L72
fixed above issue with sycl-dpcpp.pc also fixed versioning bug that was filed here https://github.com/intel/llvm/issues/23438 SPEC URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11103333/intel-dpcpp.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11103333/intel-dpcpp-7.1.1-1.fc46.src.rpm
This looks great! I think we can work any further issues within package git. Approved.
The last change was to add this blurb. Since this is a compiler it needs these reqs. # clang requires gcc, clang++ requires libstdc++-devel # - https://bugzilla.redhat.com/show_bug.cgi?id=1021645 # - https://bugzilla.redhat.com/show_bug.cgi?id=1158594 Requires: libstdc++-devel Requires: gcc-c++ SPEC URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11123845/intel-dpcpp.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11123845/intel-dpcpp-7.1.1-1.fc46.src.rpm
SPEC Url: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11123845/intel-dpcpp.spec SRPM Url: https://download.copr.fedorainfracloud.org/results/androniychuk/intel-dpcpp/srpm-builds/11123845/intel-dpcpp-7.1.1-1.fc46.src.rpm
Flags: fedora-review?
The Pagure repository was created at https://src.fedoraproject.org/rpms/intel-dpcpp Monitoring: Wasn't able to create project in Anitya. You can create it manually on: `https://release-monitoring.org`
FEDORA-2026-b47fe8876d (intel-dpcpp-7.1.1-3.fc46) has been submitted as an update to Fedora 46. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b47fe8876d
FEDORA-2026-b47fe8876d (intel-dpcpp-7.1.1-3.fc46) has been pushed to the Fedora 46 stable repository. If problem still persists, please make note of it in this bug report.