On Thu, Jan 25, 2018 at 3:52 PM, Florian Weimer <fwei...@redhat.com> wrote:
> On 01/25/2018 03:45 PM, Richard Hughes wrote:
>>
>> On 25 January 2018 at 14:28, Richard Hughes <hughsi...@gmail.com> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to