| 18 Sep 2025 |
 K900 | Seemingly | 07:52:08 |
 ghpzin | * Somebody disabled them for loongarch64 recently
https://github.com/NixOS/nixpkgs/pull/426840
and yes on top of gcc15 it fails on that test constantly. | 07:53:07 |
| ghpzin | I almost managed to build graphical iso with ~30 fixes of questionable quality.
But then mesa fails with something strange. | 08:35:38 |
| K900 | Mesa? | 08:43:48 |
| K900 | That's interesting | 08:43:50 |
| K900 | Do you have a log | 08:43:57 |
| ghpzin | FAILED: [code=1] src/nouveau/compiler/nak_bindings.rs
/nix/store/rm899xgm82kanr814dk8siwyghyxwphg-rust-bindgen-0.72.0/bin/bindgen ../src/nouveau/compiler/nak_bindings.h
/build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
Unable to generate bindings: clang diagnosed error: /build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
| 08:44:16 |
| ghpzin | FAILED: [code=1] src/nouveau/compiler/nak_bindings.rs
/nix/store/rm899xgm82kanr814dk8siwyghyxwphg-rust-bindgen-0.72.0/bin/bindgen ../src/nouveau/compiler/nak_bindings.h
/build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
Unable to generate bindings: clang diagnosed error: /build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
https://gist.github.com/ghpzin/35e5fb891645e02e5b2873761c593722 | 08:47:31 |
| K900 | https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/winsys/nouveau_bo.h?ref_type=heads#L8 | 08:47:54 |
| K900 | I wonder if GCC changed stuff around stdatomic.h | 08:49:32 |
| K900 | https://github.com/gcc-mirror/gcc/commits/releases/gcc-15/gcc/ginclude/stdatomic.h | 08:50:59 |
| K900 | Doesn't look like it at least | 08:51:03 |
| ghpzin | There was an issue upstream with that exact error, but "solution" was seemingly to just juggle installed libraries on ubuntu:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/11869 | 08:53:25 |
| K900 | Are you sure this is a GCC version thing then and not an LLVM version thing? | 08:55:37 |
| ghpzin | If you mean staging related LLVM changes, then no, it fails on top of master too.
Maybe one of the fixes in the chain somehow affects it.
Will try to minimize reproducer on master later. | 09:01:38 |
| ghpzin | * If you mean staging related LLVM changes, then no, it fails on top of master too.
Maybe one of the fixes in the gcc15 chain somehow affects it.
Will try to minimize reproducer on master later. | 09:03:23 |
 emily | it would be fun but probably next cycle is the safe move. though I worry about freeze | 10:01:55 |
| emily | actually if we're that close to the ISO then this cycle might work | 10:02:51 |
| emily | ehh probably not | 10:03:39 |
| K900 | Please do not this cycle | 10:31:03 |
| emily | yeah probably what I'll do is run GCC 15 builds while the cycle runs | 10:31:56 |
| emily | so that it's relatively ready for the next one | 10:32:05 |
| ghpzin | https://github.com/ghpzin/nixpkgs/tree/mesa-gcc15
Same error on top of current master
It only has: gcc15 default and 5 fixes to get to mesa building: ncompress, cpio, expect, yasm, woff2
Both mesa and mesa.override { stdenv = pkgs.gcc15Stdenv } seem to build fine on master | 10:32:26 |
| K900 | Exciting | 10:32:42 |
| emily | that's lovely | 10:33:01 |
| emily | if only dram was in here to snipe | 10:33:09 |
| K900 | @emily I've made it to haskell heck | 10:53:30 |
| K900 | Well this is exciting | 10:57:49 |
| K900 | webrtc-audio-processing broke by GCC 14.3 | 10:57:55 |
| K900 | Might be https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/-/commit/e9c78dc4712fa6362b0c839ad57b6b46dce1ba83 | 10:58:58 |
