On Tue, Jan 19, 2021 at 2:11 AM GitLab Bridge on behalf of Ondrej Mosnáček <cki-gitlab@xxxxxxxxxx> wrote: > > From: Ondrej Mosnáček on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/786#note_488440391 > > I think I discovered another issue with this option enabled. When I try > to build an out-of-tree kernel module on the current Rawhide compose, it > fail with: > ``` > cc1: error: incompatible gcc/plugin versions > cc1: error: failed to initialize plugin ./scripts/gcc- > plugins/structleak_plugin.so > ``` > It seems that gcc requires that the plugin has been built with the exact > same (or close enough?) GCC version as the one used to compile modules > with. That is pretty ugly, since there would now be a window between any > GCC update and the next kernel build with the new GCC, where it wouldn't > be (always) possible to satisfy the dependency (even if added as an > explicit `Requires:` to `kernel-devel`). I'm not sure though how > granular the version check is - it is possible that it mismatches so > often now because of the devel GCC snapshots that are being pushed to > rawhide these days... > > Any ideas how to fix/work around this? I was kind of hoping that this wouldn't be such a big deal in practice. As gcc11 was pushed so early, there were 3 different gcc builds in rawhide last week. This is fairly unusual, and certainly not something I would expect to see in stable Fedora. That said, we do not enable KABI and MODVERSIONS at all in Fedora, and as such, we generally expect any kmods to be rebuilt with kernel updates. I think we need to take a good look at how this works as things stabilize. Justin _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
