Re: Very strange compiler/linker related build failures in rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-07-24 at 17:59 +0200, Fabio Valentini wrote:
> On Fri, Jul 24, 2020 at 5:48 PM Jeff Law <law@xxxxxxxxxx> wrote:
> > On Fri, 2020-07-24 at 17:44 +0200, Fabio Valentini wrote:
> > > On Fri, Jul 24, 2020 at 5:11 PM Jeff Law <law@xxxxxxxxxx> wrote:
> > > > > One error I've seen in libreoffice is a gcc / annobin segfault:
> > > > > 
> > > > > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > > > > *** 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               | annobin: Generate final annotations
> > > > > PLUGIN_START_UNIT                | annobin: Generate global annotations
> > > > > PLUGIN_ALL_PASSES_START          | annobin: Generate per-function annotations
> > > > > PLUGIN_ALL_PASSES_END            | annobin: Register per-function end symbol
> > > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > > > > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > > > > internal compiler error: Segmentation fault
> > > > >  1733 |             join();
> > > > This sounds like a compiler bug.  Can you try adding
> > > > "%define _lto_cflags %{nil}"
> > > > 
> > > > To the .spec file and see if that gets you over the hump?  I've seen one failure
> > > > of this nature in my LTO testing and haven't gotten around to producing a
> > > > bugreport suitable for upstream (but the affected package has LTO disabled to
> > > > keep it from failing its builds).  My tester reports that it's never got a clean
> > > > control build of libreoffice, so I've never dug into it for any LTO specific
> > > > failures.
> > > 
> > > I added this %define _lto_cflags %{nil} to the top of the libreoffice
> > > .spec file, and compiled it in mock locally.
> > > And it spits out the same GCC crash error message without LTO.
> > THanks for checking.  That'll make things easier ;-)
> > 
> > Add -save-temps to the compile line and also build with V=1 so you can get the
> > full command line.  Pass along the .ii file and that full command line and I'll
> > take a peek at what's going on inside GCC.
> > 
> > jeff
> > 
> 
> Looks like somebody already did that and attached the .ii file to the RHBZ.
> https://bugzilla.redhat.com/show_bug.cgi?id=1859588
Unfortunately neither Marek nor I can reproduce with the compilers we've tested.
 Is it possible the OOM killer is killing the process?  Is there anything in the
system logs that might be relevant?

Jeff
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux