moxie has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
moxie has joined #dri-devel
moxie has quit []
moxie has joined #dri-devel
clamor has quit [Ping timeout: 480 seconds]
clamor has joined #dri-devel
yshui has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
warpme has quit []
fab_ has joined #dri-devel
fab_ is now known as Guest23335
Guest23335 has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
olivial has quit [Read error: Connection reset by peer]
olivial has joined #dri-devel
Company has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.7.0]
sima has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
skraitow has joined #dri-devel
nerdopolis has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
LeviYun has quit [Remote host closed the connection]
kts has joined #dri-devel
LeviYun has joined #dri-devel
moxie has quit [Quit: WeeChat 4.7.0]
illwieckz has quit [Remote host closed the connection]
moxie has joined #dri-devel
illwieckz has joined #dri-devel
moxie has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
moxie has joined #dri-devel
moxie has quit []
moxie has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
clamor has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
skraitow has quit [autokilled: This host violated network policy. If you feel an error has been made, please contact support@oftc.net, thanks. (2025-08-02 13:53:48)]
kts has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
imre has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
LeviYun has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
kts has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
gnarchie has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
dsimic is now known as Guest23345
dsimic has joined #dri-devel
Guest23345 has quit [Ping timeout: 480 seconds]
lplc has quit [Remote host closed the connection]
lplc has joined #dri-devel
kts has joined #dri-devel
YuGiOhJCJ has quit []
clamor has joined #dri-devel
gnarchie has joined #dri-devel
davispuh has joined #dri-devel
calico has joined #dri-devel
iive has joined #dri-devel
kzd has joined #dri-devel
LeviYun has joined #dri-devel
Duke`` has quit []
nchery has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
olivial has quit [Read error: Connection reset by peer]
zzyiwei has quit [Read error: Connection reset by peer]
coldfeet has joined #dri-devel
clamor has quit [Ping timeout: 480 seconds]
<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'
rasterman has quit [Quit: Gettin' stinky!]
<mareko>
gcc 13.3.0
clamor has joined #dri-devel
<mareko>
just nvk
LeviYun has joined #dri-devel
<mareko>
why don't we just use unsigned for atomics
kts has quit [Quit: Konversation terminated!]
<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
<karolherbst>
anyway, it's been there for a long time already
<mareko>
gcc 13.3.0
<karolherbst>
I'm kinda surprised why it fails to compile at all
<mareko>
I remember it failed in the past too, but I probably just ignored it
<mareko>
anyway, nothing in Mesa should ever have to use atomic_uint_fast32_t
<karolherbst>
what's the compiler invocation?
<karolherbst>
why not?
<mareko>
because we have utils for atomics
<karolherbst>
I wouldn't mind if we'd drop it all for the C11 atomic stuff either
<mareko>
apparently lots of people on the internet are having the same issue too
<karolherbst>
this somehow happens if your libclang gets updated in the meantime, and reinstalling bindgen somehow fixes it
<karolherbst>
well it doesn't happen with cargo provided bindgen
LeviYun has quit [Ping timeout: 480 seconds]
<mareko>
it's either a meson bug that should be fixed, or mesa needs better build instructions
<mareko>
"apt reinstall bindgen" doesn't fix it
<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
<karolherbst>
mareko: do you have libclang-devel for the latest version installed?
<karolherbst>
debians/ubuntus llvm/clang packaging has various issues
<karolherbst>
and this isn't the only one
<mareko>
I have libclang-dev (18) and libclang-rt-18/19-dev
<mareko>
and I build Mesa against LLVM 19
<karolherbst>
you'd need libclang-19-dev
<mareko>
oh I have both libclang-18/19-dev
<karolherbst>
ahh
<karolherbst>
maybe remove 18 if you don't need it
<karolherbst>
maybe I should debug this issue for real at some point...
<karolherbst>
but I'm just doing `cargo install bindgen-cli` and use that instead and that's not causing any issues
LeviYun has joined #dri-devel
<mareko>
"cargo install bindgen-cli" doesn't fix it for me
<karolherbst>
did you remove the distro one?
<mareko>
yes, also removed cbindgen and used cargo to get cbindgen
<karolherbst>
okay
<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
<karolherbst>
but it's been several upgrades here since I ever saw this bug, and not sure I ever saw it myself
clamor has quit [Read error: Connection reset by peer]
<mareko>
removing all llvm18 except libllvm18 fixed it
<karolherbst>
the weird part is that apparently adding it back doesn't cause a breakage
<karolherbst>
I really should find some time to investigate this
<karolherbst>
I wonder if there is a weird cache file somewhere...
<mareko>
likely the multi-version clang or llvm installations mess things up
<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
<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
<mareko>
it would be nice if Mesa didn't depend on clang or llvm
gnarchie has quit [Remote host closed the connection]