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
