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. |
2 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.