On Tue, Aug 04, 2020 at 11:24:24AM +0200, Mark Wielaard wrote:
> Hi Richard,
>
> On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote:
> > In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
> > (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
Hi Richard,
On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote:
> In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
> I'm still seeing errors like:
>
> /usr/lib/rpm/debugedit:
> /build
In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
(from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
I'm still seeing errors like:
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_v
Hi Richard,
> guestfish on x86-64 was failing for me with something that looks a lot
> like the same PLT problem. But it's not aarch64. Very easy to
> reproduce, see:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/
This l
On Fri, 2020-07-31 at 12:44 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote:
> > That binutils was rebuilt (thanks to Richard Jones) and I have now
> > built an even newer one which contains a fix for AArch64 PLT problems.
> > Both of these are built
On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote:
> Hi Guys,
>
> >> Yes, because the commit adding the DWARF 4 patch has also
> >> turned LTO back on...
>
> *double sigh*. Yes I was trying to fix the LTO bug at the same time,
> and forgot that I had re-enabled it in my local copy of
Hi Guys,
>> Yes, because the commit adding the DWARF 4 patch has also
>> turned LTO back on...
*double sigh*. Yes I was trying to fix the LTO bug at the same time,
and forgot that I had re-enabled it in my local copy of the rawhide
sources in order to investigate the problems.
That binutils wa
On Thu, Jul 30, 2020 at 10:37:22PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote:
> > On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> > > On 30/07/2020 22:18, Richard W.M. Jones wrote:
> > >
> > > >That problem is fixed, but bin
On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> > On 30/07/2020 22:18, Richard W.M. Jones wrote:
> >
> > >That problem is fixed, but binutils "ar" utility in Rawhide
> > >again segfaults, eg:
> >
> > Yes, because
On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> On 30/07/2020 22:18, Richard W.M. Jones wrote:
>
> >That problem is fixed, but binutils "ar" utility in Rawhide
> >again segfaults, eg:
>
> Yes, because the commit adding the DWARF 4 patch has also
> turned LTO back on...
Since this i
On 30/07/2020 22:26, Tom Hughes via devel wrote:
On 30/07/2020 22:18, Richard W.M. Jones wrote:
That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:
Yes, because the commit adding the DWARF 4 patch has also
turned LTO back on...
...and for extra fun the broken bu
On 30/07/2020 22:18, Richard W.M. Jones wrote:
That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:
Yes, because the commit adding the DWARF 4 patch has also
turned LTO back on...
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
_
On Thu, Jul 30, 2020 at 10:18:18PM +0100, Richard W.M. Jones wrote:
>
> That problem is fixed, but binutils "ar" utility in Rawhide
> again segfaults, eg:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210
> https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log
>
>
That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210
https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log
https://koji.fedoraproject.org/koji/taskinfo?taskID=48213712
https://kojipkgs.fedor
Thanks Nick, the binutils change does appear to have solved the
problem:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48212537
https://kojipkgs.fedoraproject.org//work/tasks/2537/48212537/build.log
Note (for Xavier) that I did NOT need to make any change to OCaml or
the flags that it pass
Hi Guys,
> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.
Yes - it was a silly snafu. I set the default to 4 but the tests are expecting
3.
I have now updated the patch and a new binutils (2
Hi Guys,
> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
Hi Richard,
On Thu, 2020-07-30 at 12:01 +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> > I will apply this patch to the rawhide binutils (and the upstream
> > binutils sources).
>
> I don't know how worried we should be about this, but it seems
On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> I will apply this patch to the rawhide binutils (and the upstream binutils
> sources).
I don't know how worried we should be about this, but it seems every
test in the x86-64 build failed (although the build was successful):
https:/
On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> Hi Guys,
>
> > But... in 2.35 you can give the DWARF level you want.
> > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> > dwarf_level is never set! And then gas will happily create an
> > .debug_info section w
Hi Guys,
> But... in 2.35 you can give the DWARF level you want.
> The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> dwarf_level is never set! And then gas will happily create an
> .debug_info section with DWARF CUs that have a version of zero (!).
Doh!
> This, defaulting t
Hi Jakub,
On Wed, 2020-07-29 at 19:10 +0200, Jakub Jelinek wrote:
> On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> > Yes, I think we have a winner!
> > gas generates a tiny bit of debuginfo even if you don't supply -g.
> >
> > But... in 2.35 you can give the DWARF level you want
Hi Richard,
On Wed, 2020-07-29 at 17:55 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> > This, defaulting to version 4. Fixes it for me:
> >
> > diff --git a/gas/as.c b/gas/as.c
> > index 4c5881abd88..c2da78870ef 100644
> > --- a/gas/as.c
> > +
Hi Xavier,
On Wed, 2020-07-29 at 18:50 +0200, Xavier Leroy wrote:
> If we need to add a directive to the generated assembly, or pass a `-g`
> option to the assembler, or use `gcc -c -g` as the assembler, let us know
> and we'll see what we can do.
>
> However, please keep backward compatibility i
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> Yes, I think we have a winner!
> gas generates a tiny bit of debuginfo even if you don't supply -g.
>
> But... in 2.35 you can give the DWARF level you want.
> The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> d
On Wed, Jul 29, 2020 at 10:56 AM Jerry James wrote:
> No, it is just called like this: as -o hacha.o hacha.s. Anyway, "info
> ld" claims that the -g flag is ignored.
No, that was the old "info ld" that said that. The -g flag isn't even
mentioned in the new binutils info page. But it is necessa
On Wed, Jul 29, 2020 at 06:50:43PM +0200, Xavier Leroy wrote:
> However, please keep backward compatibility in mind: from the Info manual
> it looks like gas version 2.34 has no `-g` option and no directives to
> control the generation of DWARF information. So there should be reasonable
> defaults
On Wed, Jul 29, 2020 at 10:51 AM Mark Wielaard wrote:
> I also tried to do a mockbuild locally, and that one succeeded.
> Don't know what is different from the koji buildroot :{
Run mock with --enablerepo=local.
> So ml depends on binutils gas to generate the actual debuginfo.
> I assume it gets
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> Hi,
>
> On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote:
> > (Adding OCaml author)
>
> (Adding binutils/gas maintainer)
>
> > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> > > On Wed, 2020-07-29 at 16
I got so focused on the other thread, I didn't pay attention to this one.
On Wed, Jul 29, 2020 at 10:02 AM Richard W.M. Jones wrote:
> 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
Hi,
On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote:
> (Adding OCaml author)
(Adding binutils/gas maintainer)
> On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> I should probably add that I'm building th
(Adding OCaml author)
On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> Hi Richard,
>
> On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> > On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > > Given these are .ml files I suspect it is not gcc, but some
Hi Richard,
On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > 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 tho
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: Em
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
> >
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/
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
/
37 matches
Mail list logo
