* Laura Abbott: > I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel > since I've heard some people express interest in stackleak (I'm interested > as well). a gcc plugin gets built as an .so file for use during > compilation. This means we need to package this .so file as part > of kernel-devel for building external modules. This is easy to > do but it also now introduces a tighter restriction on the toolchain > used for building modules since gcc will refuse to load a plugin and > fail to build the module if the versions don't match. Arguably, there's > always been a requirement to use the same toolchain version but there may > have been some flexibility for forcing it. > > Can anyone see major problems with requiring the same toolchain > version for building external modules as the kernel? If those kernel modules happen to build userspace components as well (and use the right build flags), then they have such a toolchain dependency already, indirectly through the annobin plugin. The main caveat I see is that it is tricky to handle the version constraints correctly (both in the plugin and at the RPM level). For a long time, the annobin constraints were too tight. Cc:ing Nick in case he wants to add any comments. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
