Re: GCC plugins packaging (for AFL++)
Florian Weimer <[email protected]> Tue, 21 Jul 2026 12:00:22 +0200
| Newsgroups | gmane.linux.redhat.fedora.devel |
|---|---|
| Message-ID | <[email protected]> |
* Richard W. M. Jones: > On Thu, Jun 25, 2026 at 06:21:01PM +0200, Florian Weimer wrote: >> * Richard W. M. Jones: >> >> > Apparently GCC plugins depend on the exact GCC major.minor.release >> > version (rather than, say, just the major version as with Clang). Or >> > AFL *thinks* it needs to depend on the exact version, although you >> > could set an environment variable to skip the check, see: >> > >> > https://github.com/AFLplusplus/AFLplusplus/blob/edaf3ad04d64185cae856c75ca4676cbb14a35b5/instrumentation/afl-gcc-pass.so.cc#L621 >> > >> > Do GCC plugins really depend on the exact major.minor.release of GCC? >> >> They do. We rebuild the annobin plugin each time we update GCC, and >> reconfigure to use that annobin version if the separately built annobin >> plugin was built by a different GCC version (and not the currently >> installed one). > > Sorry for the late reply here. > > I don't have any good ideas here, except that I want to avoid having > to rebuild AFL every time we rebuild GCC. That's not going to make > anyone happy. > > Is there a stable subset of APIs or is there just no hope? Thinks like the GCC options array are unstable, so there's really no good way to avoid recompilation. How often do you expect to update AFL? We could build the plugin during the GCC build itself, perhaps. Thanks, Florian -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new