18:09 mareko: how to resolve this Mesa build issue? syn-2-rs| ERROR: Subproject unicode-ident is buildable: NO
18:33 zzyiwei: mareko: git clean -xdf subprojects
18:35 zzyiwei: for details, see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36284#note_3024937
18:37 mareko: thanks, that worked
18:43 mareko: the only thing that doesn't build is nouveau: .../src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
18:44 mareko: gcc 13.3.0
18:45 mareko: just nvk
18:50 mareko: why don't we just use unsigned for atomics
18:52 karolherbst: mareko: on what compiler does this fail to compile? Because this is a C11 feature. Also the atomic types don't need any of the atomic function calls, though I don't really mind either way
18:53 karolherbst: anyway, it's been there for a long time already
18:53 mareko: gcc 13.3.0
18:55 karolherbst: I'm kinda surprised why it fails to compile at all
18:55 mareko: I remember it failed in the past too, but I probably just ignored it
18:56 mareko: anyway, nothing in Mesa should ever have to use atomic_uint_fast32_t
18:56 karolherbst: what's the compiler invocation?
18:56 karolherbst: why not?
18:56 mareko: because we have utils for atomics
19:01 karolherbst: I wouldn't mind if we'd drop it all for the C11 atomic stuff either
19:02 mareko: karolherbst: it's due to rust, see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11869
19:03 karolherbst: ohh it's this bindgen bug...
19:04 karolherbst: or rather a weird packaging issue
19:05 mareko: apparently lots of people on the internet are having the same issue too
19:05 karolherbst: this somehow happens if your libclang gets updated in the meantime, and reinstalling bindgen somehow fixes it
19:05 karolherbst: well it doesn't happen with cargo provided bindgen
19:06 mareko: it's either a meson bug that should be fixed, or mesa needs better build instructions
19:07 mareko: "apt reinstall bindgen" doesn't fix it
19:07 karolherbst: it's not something meson can fix, it's just the bindgen invocation itself doesn't find the right libclang version, and somehow if you have multiple libclang version it's gonna cause issues
19:07 karolherbst: mareko: do you have libclang-devel for the latest version installed?
19:08 karolherbst: debians/ubuntus llvm/clang packaging has various issues
19:08 karolherbst: and this isn't the only one
19:09 mareko: I have libclang-dev (18) and libclang-rt-18/19-dev
19:09 mareko: and I build Mesa against LLVM 19
19:10 karolherbst: you'd need libclang-19-dev
19:10 mareko: oh I have both libclang-18/19-dev
19:10 karolherbst: ahh
19:10 karolherbst: maybe remove 18 if you don't need it
19:11 karolherbst: maybe I should debug this issue for real at some point...
19:11 karolherbst: but I'm just doing `cargo install bindgen-cli` and use that instead and that's not causing any issues
19:13 mareko: "cargo install bindgen-cli" doesn't fix it for me
19:13 karolherbst: did you remove the distro one?
19:14 mareko: yes, also removed cbindgen and used cargo to get cbindgen
19:15 karolherbst: okay
19:15 karolherbst: I might need to create a VM to properly dig into it and figure out what's wrong, but so far the condition to trigger is, that if you used it with an older libclang, and then an upgrade pulls in a new one, and something gets confused, so just having one libclang version usually fixes it
19:16 karolherbst: but it's been several upgrades here since I ever saw this bug, and not sure I ever saw it myself
19:18 mareko: removing all llvm18 except libllvm18 fixed it
19:19 karolherbst: the weird part is that apparently adding it back doesn't cause a breakage
19:20 karolherbst: I really should find some time to investigate this
19:24 mareko: something here fixed it: https://gitlab.freedesktop.org/freedesktop/snippets/-/snippets/7853
19:25 karolherbst: I wonder if there is a weird cache file somewhere...
19:26 mareko: likely the multi-version clang or llvm installations mess things up
19:28 karolherbst: yeah..., so there is this clang-sys rust lib bindgen uses indirectly and it uses libloading to figure out what native libraries to load and it either links statically or dynamically
19:29 karolherbst: but anyway, gtg, maybe I'll look into it tomorrow or something, but I think it's just some weird chain of events leading to this
19:31 mareko: it would be nice if Mesa didn't depend on clang or llvm
21:30 karolherbst: getting rid of clang and llvm would certainly a project
21:30 karolherbst: *be a