!eWOErHSaiddIbsUNsJ:nixos.org

NixOS CUDA

290 Members
CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda57 Servers

Load older messages


SenderMessageTime
10 Jan 2026
@glepage:matrix.orgGaétan Lepage *

Sure, done: https://github.com/NixOS/nixpkgs/pull/478681

EDIT: merged by happysalada

11:34:03
@snaky_eyes:matrix.orgGilles Poncelet joined the room.15:34:07
@connorbaker:matrix.orgconnor (he/him)

Suppose you’ve got a project where different object files are compiled with different versions of NVCC/GCC. Under what conditions can they be linked into shared objects?

As an example, assume you’ve got a project which builds with an older version of CUDA, and you’re using stdenv (not cudaPackages.backendStdenv). The CUDA portion of the build would produce object files using an older, NVCC-compatible GCC (by virtue of how we wrap NVCC so it always sees a compatible GCC), but the rest would produce object files using the GCC provided by stdenv. Linking happens with some combination of stdenv’s linker, the linker corresponding to the bintools (I think) of the GCC available to NVCC, and NVLink.

Under what conditions would linking succeed?

I ask because I remember trying to use multiple versions of LLVM-produced object files and getting something along the lines of a bitstream version mismatch, but I don’t remember if that was because I was using LTO or something else.

16:45:25
@ss:someonex.netSomeoneSerge (back on matrix)I'm pretty sure there are no compatibility guarantees, but idk under what conditions it might work by accident17:00:55
@ss:someonex.netSomeoneSerge (back on matrix)But this still fails early, no?17:04:11
@glepage:matrix.orgGaétan LepageYes, because this package is not available for cuda 12.819:46:18
@ss:someonex.netSomeoneSerge (back on matrix)
In reply to @glepage:matrix.org
Yes, because this package is not available for cuda 12.8
But this should not be an eval error, unless via meta.unsupported or meta.broken
20:06:56
11 Jan 2026
@ivank:matrix.orgivan joined the room.01:55:43
@glepage:matrix.orgGaétan Lepage FYI, merged the onnx 1.20.1 update
https://github.com/NixOS/nixpkgs/pull/478567
09:31:04
@9hp71n:matrix.orgghpzin changed their display name from ghpzin (moved to @ghpzin:envs.net) to ghpzin.15:04:47
@ghpzin:envs.net@ghpzin:envs.net left the room.16:16:27
@connorbaker:matrix.orgconnor (he/him)Anyone want to start on the OpenCV bump if there isn’t one already 🫩18:50:29
@glepage:matrix.orgGaétan Lepage Sure, opened https://github.com/NixOS/nixpkgs/pull/479136. Not tested yet. 20:19:53
@glepage:matrix.orgGaétan Lepage

After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!

Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587

23:30:41
@glepage:matrix.orgGaétan Lepage *

After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!

Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587

EDIT: still fails with cudaSupport and rocmSupport :')

23:36:02
@glepage:matrix.orgGaétan Lepage *

After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!

Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587

EDIT: still fails with cudaSupport and rocmSupport :')
EDIT2: turns out they seem to have removed Rocm support (https://github.com/microsoft/onnxruntime/pull/25181)

23:59:01
12 Jan 2026
@9hp71n:matrix.orgghpzin Madouura has not been active for over a year and their maintainer entry was removed, probably better to ping rocm team.
From PR description they seem to have removed support for ROCM EP and expectation is to use MIGraphX EP instead.
https://onnxruntime.ai/docs/execution-providers/ROCm-ExecutionProvider.html
NOTE ROCm Execution Provider has been removed since 1.23 release. Please Migrate your applications to use the MIGraphX Execution Provider
00:28:11
@glepage:matrix.orgGaétan Lepage

Thanks for the heads up regarding Madouura's situation.

Considering the amount of code removed, I wondered whether we could still do something.

08:58:39
@glepage:matrix.orgGaétan Lepage

Thanks for the review connor (burnt/out) (UTC-8). Anything left to consider before merging?

I didn't spot any major regressions.

15:45:59
@glepage:matrix.orgGaétan Lepage opencv4Full with cudaSupport looks problematic actually. 15:49:06
@connorbaker:matrix.orgconnor (he/him)I didn't build for aarch64-linux (with or without CUDA) or for any darwin platforms, so I guess there's still that. As a general concern with larger rebuilds around this size it's the "use your discretion" vs. "always target staging" divide.15:49:52
@connorbaker:matrix.orgconnor (he/him)How so?15:50:07
@glepage:matrix.orgGaétan LepageNevermind, it's already broken. Not a regression.15:50:46
@glepage:matrix.orgGaétan Lepage

hexa (UTC+1) suggested that it could be merged into master.

I'll try to build it on the other platforms.

15:52:23
@hexa:lossy.networkhexayou can throw opencv on top of staging-next which started earlier15:53:09
@connorbaker:matrix.orgconnor (he/him)To clarify, can or should?15:53:42
@hexa:lossy.networkhexaslight preference15:54:13
@hexa:lossy.networkhexabecause while these were 500-1000 builds they gravitated to the more annoying end of builds15:54:29
@glepage:matrix.orgGaétan Lepage Ok, I'll target staging-next once I'm done building for all platforms 15:55:50
@connorbaker:matrix.orgconnor (he/him)Any thoughts on whether it’s suitable for backport to 25.11? Would unbreak CUDA 13 functionality there which I welcome17:09:22

Show newer messages


Back to Room ListRoom Version: 9