You are not logged in.
gcc/plugin.c:
bool
plugin_default_version_check (struct plugin_gcc_version *gcc_version,
struct plugin_gcc_version *plugin_version)
aha.
Well, the error message in the kernel plugin is not nice at all: it should say something like:
cc1: error: incompatible gcc/plugin versions (gcc is 10.1.2, kernel is 10.3.0)
or something along those lines..
Offline
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/plugin/include/plugin.h:extern bool plugin_default_version_check (struct plugin_gcc_version *,
that sounds reasonable, so let's check on IA-32:
grep -r plugin_default_version_check /usr/lib/gcc
/usr/lib/gcc/i686-pc-linux-gnu/11.2.0/plugin/include/plugin.h:extern bool plugin_default_version_check (struct plugin_gcc_version *,
Sounds about right. Ok. debugging it is..
Offline
@abaumann - just to stay with the thread, i got the same result, again. have already rebuilt and the rebuild works fine. if there's any information we can provide to help figure out where the disconnect is happening, just let us know.
plugin_default_version_check comes with gcc, which i think you've already figured out.
Offline
@abaumann - same issue with 5.18.1. about to rebuild.
Offline
@abaumann - definitely worth a try, bud.
i was setting up a build and noticed too that the r8168 and r8101 dkms packages wouldn;t build under my rebuilt 5.18.1 kernel. although an updated version of r8168 was available (and which *does* build - i used it as a template to modify r8101 which also builds now), i found it really strange that neither of those modules needed *any* updating under arch64... as if the core 5.18.x kernel api was different between the 2 platforms, which should never happen under normal circumstances. is it possible that one or more config flags either are being set when they shouldn;t be, or aren;t being set when they should be? i can look into this if you want. i have older 32-bit live system images i can boot up and grab a /proc/config.gz and compare it, but i can't say for sure i can recognize a possible discrepancy unless it's obvious.
i'm beginning to think i should just do a pacman dump on all my installed packages and let you do a version comparison against your build system. we're out of sync somewhere...
Offline
@abaumann - so. what'd you do to fix it, bud? linux-5.18.3 installed perfectly along with its dkms modules, so something got realigned somewhere. i had had to rebuild 5.18.1, so something happened between versions 5.18.1 and 5.18.3...
Offline
@abaumann - i went ahead and closed this post since your linux-5.18.3 release seems to have resolved the problem. i *would* like to know what fixed it, though. was it baking the rule into the buildmaster, so that toolchain/linux updates happen in sync? or did you find a single point of mis-versioned something somewhere?
Last edited by jghodd (2022-06-29 19:23:48)
Offline
maybe this fixes the issue for core/linux-headers
Offline
Maybe but doesn't that mean you need to update whatever controls srcname/.config whenever gcc changes enough version to care about?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
IIUC, .config is updated in the prepare() step by make olddefconfig
Offline