16:21 <ukleinek> lag: commit 841165267827955bb3295b066cb6a906ba9265c0 (from https://lore.kernel.org/linux-leds/169054337847.351209.7864098481511406737.b4-ty@kernel.org) isn't in next yet. I assume you would have told if there was a problem with that patch, so you forgot to push it out?

19:35 <nathanchance> arnd: Thanks for fixing that error! FWIW, I seem to running into a similar issue as Rob with regards to linking the gcc plugins now (https://paste.debian.net/plainh/a68c0b79) but that seems expected for the reasons you noted earlier. I’ll just specify CONFIG_GCC_PLUGINS=n for now.

19:38 <arnd> nathanchance: I think turning off GCC plugins would have addressed your first problem as well, so it sounds the update has not actually achieved much here

19:39 <arnd> nathanchance: which compiler and libstdc++ version are you using to build the plugin?

19:54 <nathanchance> arnd: Yes, you’re right. My host GCC shows ‘gcc (GCC) 13.2.1 20230801’ and I think my libstdc++ version is 6.0.32?

19:59 <arnd> nathanchance: that's actually pretty close to what I have, with with gcc 13.1.0-2 and libstdc++.so.6.0.32

20:03 <arnd> apparently the symbol is "frange::accept(vrange_visitor const&) const", but so far I haven't even found where that is defined

20:13 <arnd> nathanchance: the symbol comes from gcc/gcc/value-range.cc and was added in gcc-13, which would indicate that the link failure is maybe not the result of something I did but rather a problem with gcc-13 in general

20:14 <arnd> it could also be related to the missing header that I worked around, possibly both are the result of building a C-only compiler when the default build would include c++ as well

20:15 <nathanchance> arnd: Yeah, that is totally possible, as the plugins are built with HOSTCXX

20:16 <arnd> I think all plugins are built with a c++ compiler because that's what gcc is written in these days, if that didn't cause problems before