On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote:
> > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails
> > > with:
> > > 
> > >   error: Empty %files file 
> > > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list
> > > 
> > > However it works when I build locally:
> > > 
> > >   $ rpm -qlp 
> > > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm
> > >   /usr/src/debug/hevea-2.34-7.fc33.x86_64
> > >   /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build
> > >   /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml
> > >   /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml
> > >   /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml
> > >   [etc]
> > > 
> > > There's an earlier error which occurs in the Koji build which doesn't
> > > occur for me locally but looks related:
> > > 
> > >   Dwarf Error: wrong version in compilation unit header (is 0, should be 
> > > 2, 3, 4 or 5) [in module 
> > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha]
> > >   gdb-add-index: No index was created for 
> > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha
> > >   gdb-add-index: [Was there no debuginfo? Was there already an index?]
> > > 
> > > Did something change with DWARF or gdb in Rawhide that we should be
> > > aware of?  Obviously these are not C code and OCaml has its own DWARF
> > > generator.
> > 
> > I think mjw is tracking something like this yesterday, but it was aarch64.  
> > I'm
> > going to be offline for a couple hours, but you might want to reach out to 
> > him
> > and see if there's any useful state (on cc)
> 
> This looks unrelated to what I was looking at, which was indeed aarch64
> specific (but doesn't actually seem to be impacting the mass rebuild):
> https://bugzilla.redhat.com/show_bug.cgi?id=1861423
> 
> The above happens if none of the debuginfo could be read at all, so no
> source files could be extracted.
> 
> Given these are .ml files I suspect it is not gcc, but some other
> code/DWARF generator issue. Maybe it does use the default (binutils)
> liker though?

It uses its own DWARF generator but everything is linked together
using standard binutils (via GCC).

> Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we
> can inspect it?

I've uploaded the binary which I built on my own machine here:

http://oirase.annexia.org/tmp/hacha.native

plus some of the *.o files which went into it:

http://oirase.annexia.org/tmp/myLexing.o
http://oirase.annexia.org/tmp/myStack.o
http://oirase.annexia.org/tmp/hacha.o

I also saved an asm file from one of them which may be helpful:

http://oirase.annexia.org/tmp/hacha.s

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to