On Tue, Feb 06, 2024 at 11:54:23AM +0000, Richard W.M. Jones wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034 > https://bugzilla.redhat.com/show_bug.cgi?id=2262539 > > The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears > to be building a GCC plugin, contained in one or all of these newly > added files: > > %global afl_helper_path %{_libdir}/afl > %{_bindir}/afl-gcc-fast > %{_bindir}/afl-g++-fast > %{afl_helper_path}/afl-gcc-cmplog-pass.so > %{afl_helper_path}/afl-gcc-cmptrs-pass.so > %{afl_helper_path}/afl-gcc-pass.so > %{afl_helper_path}/afl-gcc-rt.o > %{afl_helper_path}/injection-pass.so > > I'm going to guess this will introduce a dependency on the exact > version of GCC (major only? or major.minor? not sure). Just like > annobin. Which might require that this package is rebuilt when GCC is > rebuilt (only major? or all rebuilds? again, don't know). > > If this proves to be a problem then I can drop the GCC plugin usage, > or we could work out a process to deal with rebuilding. > > Anyway, let's look out for this and see if it causes trouble, and then > decide what to do. Guess it depends on what exactly it uses. Obviously, there must be a dependency on the major version. The plugin API (which is essentilly everything in the compiler) can change obviously at any time, but in reality on release branches (at least past the major.1 release) it doesn't change much very often, from the annobin experience the only major problematic thing are accesses to options - global_options{,_set} and the like, including through macros like flag_* or opt_for_fn etc. As described in https://gcc.gnu.org/r11-5149 , annobin has some code to find out offsets of options in global_options{,_set} etc. even if it has been built against different version of gcc (same major, but from different date), where perhaps some options have been added or removed and that in turn caused reshuffling of options which were there before and are still in there but at different offsets. Jakub -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
