On Thu, Jan 25, 2018 at 3:52 PM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 01/25/2018 03:45 PM, Richard Hughes wrote: >> >> On 25 January 2018 at 14:28, Richard Hughes <hughsient@xxxxxxxxx> wrote: >>> >>> Was there a test mass rebuild? If so, how many packages need fixes? I >>> got bitten by this just now and it would have been nice to fix the >>> problems upstream before Fedora rebuilds just started failing. >> >> >> Replying to myself, trying to fix it (by adding the "missing" private >> library to the plugins) and rebuilding I triggered a gcc bug on i386: >> >> *** WARNING *** there are active plugins, do not report this as a bug >> unless you can reproduce it without enabling any plugins. >> Event | Plugins >> PLUGIN_FINISH_UNIT | Generate final annotations >> PLUGIN_START_UNIT | Generate global annotations >> PLUGIN_ALL_PASSES_END | Generate per-function annotations >> ../src/fu-device-locker.c: In function >> 'fu_device_locker_class_intern_init': >> ../src/fu-device-locker.c:49:1: internal compiler error: in >> ix86_expand_prologue, at config/i386/i386.c:14572 >> G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT) > > > Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648 > > I can perhaps put a workaround in redhat-rpm-config, which should make it > much less likely that this compiler bug is encountered. Rebuilding gcc > takes 15+ hours, unfortunately, and untagging it will only revert to a > version which miscompiles OpenSSH and RPM. 8-( Honestly, if the "-z defs" change leads to such massive problems, maybe it really should be considered to revert this change for f28 - if only to give upstream developers and package maintainers more time for fixes. I can imagine overworked maintainers with dozens of broken packages ignoring the issues or just putting the "%undef" into their packages without investigating (which would cost more time), possibly obscuring real issues. I think enabling this change again right after the f28 mass rebuild and branching would be the best, giving maintainers the most time. Fabio > Thanks, > Florian > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
