sys-devel/DPC++: Update to nightly 2026.06.18#1402
Conversation
|
I also have an updated oneDPL ebuild but since it depends on this, I have decided not to include it in this PR until I get feedback on this PR/this PR gets merged. I also didn't want to touch the package.mask entry of these packages to keep the PR as single issue as possible. |
|
Hi, first of thanks for looking into this! However the verbosity of the PR description is very LLM-suspicious. Just in case you did not know here is gentoo's AI policy https://wiki.gentoo.org/wiki/Project:Council/AI_policy. |
|
@APN-Pucky Sorry about the verbosity, no AI was used in this PR nor on the description. I am just a very verbose person (example). I have been personally using this modified ebuild for a month now and upstream intel/llvm kept changing things that made me run into issues which slowly lead to the accumulation of the changes in this PR. I just wanted to explain basically everything that makes it different from the existing ebuilds to avoid a lengthy back and forth. Last time I contributed to an open source project (funnily enough it was LLVM), I spent like a week in the PR review process over trivial things and just wanted to reduce the friction as much as possible. |
|
Thanks! No problem and being verbose is good. I will review and test it coming week. |
| # Install all other files into the same temporary directory | ||
| cmake_build install |
There was a problem hiding this comment.
not sure, just checking: Shouldn't this go into src_install?
There was a problem hiding this comment.
This part was inherited from the original ebuilds. I believe this command was originally here because there are parts of the llvm project that werent compiled by the deploy-sycl-toolchain target (such as other runtimes like the OpenMP runtime), so this command ended up compiling everything else since everything is a dependency of the install target. I believe you are right that it should belong on src_install so I replaced this line with cmake_src_compile so that it finishes compiling in the src_compile function and moved the cmake_build install to be the first line of the src_install function. Please resolve if you think this solution is good.
|
Thanks. I tried to fetch it but noticed that your commits do not have a sign-off line (See https://devmanual.gentoo.org/general-concepts/copyright-policy/index.html). You can squash the two commits and add it ( |
$ pkgcheck scan --commits
sys-devel/DPC++
DoubleEmptyLine: version 2026.06.18: ebuild has unneeded empty line on lines: 68, 88
ExcessiveLineLength: version 2026.06.18: excessive line length (over 120 characters) on line: 43
NonexistentDeps: version 2026.06.18: DEPEND: nonexistent package: >=dev-cpp/parallel-hashmap-1.3.12
NonexistentDeps: version 2026.06.18: RDEPEND: nonexistent package: >=dev-cpp/parallel-hashmap-1.3.12::sci does not have parallel-hashmap. it is only in ::guru. adding @Nowa-Ammerlaan : should we duplicate it in ::sci or move it from ::guru to ::gentoo? |
|
Given you need very recent spirv-headers I don't think indirectly depending on the latest 9999 version is correct here. Since this ebuild will not support ~amd64 keywording then as it's dependencies do not. |
Maybe the best would be to have this ebuild be ** keyworded and can be brought to ~amd64 keywording at the next release of the vulkan sdk? Its also a random nightly build so maybe ** keywording is the most appropriate anyways. |
|
Squashed and signed off as requested |
something fails for me. I am running in the supposed network-sandbox so it can not Fetch anything from the network. |
|
Do you not have level-zero installed? It is a requirement. The build system will try to fetch any of the requirements that aren't installed which is annoying. Edit: Wait nvm I see that it requires a newer version of level-zero than the amd64 keyworded one. |
Signed-off-by: Emilio M <emendoz@clemson.edu>
|
Now it should pull in the correct level-zero version |
Co-authored-by: Alexander Puck Neuwirth <APN-Pucky@users.noreply.github.com>
|
It pulled/instealled dev-libs/level-zero-1.30.0 now first, but then similar, but different: |
|
@Emimendoza you can check it yourself by setting (some of) the following features for test installing the ebuild: $ FEATURES="network-sandbox preserve-libs sandbox test userpriv usersandbox" emerge/ebuild sys-devel/DPC++ |
|
I vaguely remember bumping into that same problem before, could be a merged-usr/split-usr thing where it does not find the libraries it is looking for. |
3 participants
Rationale of changes when compared to previous ebuilds.
Why nightly and not latest official release (6.3.0*)?
Originally I was trying to port the latest official release but DPC++ is very tightly coupled to level-zero, so it would either involve requiring an old version of level-zero installed, or adding slotted level-zeros, or bundling level-zero. This option seemed the least painful.
*: the proprietary compiler follows the yyyy.mm.dd versioning format but their open source releases follow major.minor.patch format; its weird
Why require such a weird version of spirv-headers which can (currently) only be satisfied by the live version?
This commit bumps the required spirv-header version to one that is newer than the latest tag on the spirv-headers github. Khronos tags spirv-headers based off of releases to the vulkan sdk and that's what gentoo uses for their package versions. So as it currently stands, only the live version of the headers contain the required spirv extensions but the next vulkan sdk release will most probably have them; this way there won't be a need to update this ebuild when the time comes.
What's with dev-cpp/parallel-hashmap requirement?
It is required to build the sycl toolchain, fortunately guru contains a compatible version.
What's with bundled emhash, unified-memory-framework and no longer bundling unified-runtime?
Unified-Runtime got upstreamed to intel/llvm so it is compiled with DPC++ in this ebuild, however, it relies on unified-memory-framework which is not upstreamed into intel/llvm. UMF could probably be unbundled but I havent come accross a project that uses UMF but not UR. Emhash is required to compile DPC++ but no ebuilds exist for it in any overlay (that I could find).
Why did you remove the esimd_emulator USE flag?
The project has been archived by intel a while ago.
What is with the offload UR_* unused cmake arguments?
There is a unified-runtime offload backend which used to build with this ebuild (nightly version 2026-08-07 and before) but upstream changed the installation path of liboffload.so and the offload backend no longer compiles. This isn't an issue unique to this ebuild, they broke their own github CI jobs doing so and have decided to simply disable them instead of addressing the breaking commit. I left most of the ebuild intact so that it should be as simple as adding ";offload" to LLVM_ENABLE_RUNTIMES and setting UR_BUILD_ADAPTER_OFFLOAD to ON and uncommenting the "cmake_build runtimes/install" line in src_compile() once the issue is fixed or someone feels like making a patch reverting the commit.
Why are you compiling the LLVM toolchain as static?
We need to compile llvm as a static library because otherwise libsycl.so crashes at runtime because it dlopen's the intel graphics compiler dynlib which pulls in its own llvm dynlib. If it weren't for that it also might crash because something is pulling in vulkan and mesa's vulkan implementation also pulls in its slotted llvm dynlib. This is the path of least resistance. For context, intel's official binary debian packages statically link the llvm components to intel graphics compiler. We don't do that in the igc ebuild (which is in the main gentoo repo).
What is this DPC++-6.3.0-zstd.patch?
The sycl project ignores the LLVM_USE_STATIC_ZSTD cmake variable and will unconditionally try to link to static zstd, which might not exist. The version comes from me originally porting 6.3.0 (please see first item in this PR for clarification) and I decided to keep the name since it is the latest stable release which requires such patch, this way if future nightly ebuilds are released, they wont all require their own versions of this patch and this makes more sense than to have them all use the same patch but just have a random nightly version as the version name in the patch.