On 2/15/19 3:47 AM, Florian Weimer wrote:
* 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.
Most modules are probably not going to be compiling userspace
components so I'm not too concerned there.
Thanks for the pointer to annobin though, I hadn't thought about
how to actually specify the requirement in the rpm file. I'm
not sure if this example convinces me I should do gcc plugins
or it's not worth the hassle.
Laura
_______________________________________________
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
