On Tue, Jan 2, 2024 at 7:20 PM Peter Robinson <pbrobin...@gmail.com> wrote:
>
> On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov
> <david.abdurachma...@gmail.com> wrote:
> >
> > On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson <pbrobin...@gmail.com> wrote:
> > >
> > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
> > > <david.abdurachma...@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer <fwei...@redhat.com> 
> > > > wrote:
> > > > >
> > > > > * David Abdurachmanov:
> > > > >
> > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones 
> > > > > > <rjo...@redhat.com> wrote:
> > > > > >>
> > > > > >>
> > > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > > > > >> raise it here to get the attention of the Fedora toolchain team ...
> > > > > >>
> > > > > >> Here's the bug:
> > > > > >>
> > > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 
> > > > > >> objects
> > > > > >>
> > > > > >> It refers to this change in binutils 2.41:
> > > > > >>
> > > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > > >>
> > > > > >> As far as I understand the issue (which is not too far) this mainly
> > > > > >> affects shipped *.o and *.a files (ie. static libraries and 
> > > > > >> similar)
> > > > > >> which were compiled with binutils < 2.41, which either won't link
> > > > > >> correctly or will give a linker error when using GNU ld from 
> > > > > >> binutils 2.41.
> > > > > >
> > > > > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > > > > binutils release).
> > > > > >
> > > > > >>
> > > > > >> Unclear if it also affects *.so files (which would be a much more
> > > > > >> serious ABI break), and also if it affects most binaries or just a
> > > > > >> few.  I initially thought this only affected programs using 128 bit
> > > > > >> ints, so didn't think it was too important, but after reading the
> > > > > >> commit I'm not sure that is really true.
> > > > > >
> > > > > > Nelson Chu committed (5 days ago) a change:
> > > > > >
> > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > > >
> > > > > > This will accept whatever is produced by <= 2.41 and the final 
> > > > > > binary
> > > > > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > > > > can produce a warning if it detects an issue.
> > > > > >
> > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would 
> > > > > > happen
> > > > > > before I start mass rebuilding, and that should fix this.
> > > > >
> > > > > Cc:ing Nick and Siddhesh for awareness.
> > > > >
> > > > > The current plan is to use binutils 2.41 for the mass rebuild.
> > > >
> > > > In Fedora/RISCV we typically end up using the latest available
> > > > binutils. We are slightly different from upstream/normal Fedora.
> > >
> > > Which is fine when you're an out of mainline architecture but these
> > > sorts of things need to be resolved well and truly before any
> > > incorporation can happen.
> >
> > 100% true. We have plenty of stuff that isn't yet submitted to the
> > official dist-git.
>
> Is that delta easily viewable somewhere?

Kinda.

If you list all the builds for the f40 tag in Fedora/RISCV Koji, and
then look for the .X.riscv64 pattern before %{?dist} you will get a
list of packages that are modified in some way. Today that's around
~277 packages. A good portion of those are easy fixes (e.g. a lot of
packages assume that valgrind is available on just any arch, and never
check %{valgrind_arches}). Some of the changes are bigger, like full
ports, that for one or another reason were not accepted upstream
(yet).

Not all the changes are good to for a PR. Thus some definitely need
some refinement to do the correct thing.

Then actual changes are here: http://fedora.riscv.rocks:3000/rpms/<pkg_name>
Typically this should have a branch with "-riscv64" suffix, e.g.,
f38-riscv64 or main-riscv64.

I hope to reduce that to a minimum during Fedora 40, but I am not
making any promises.

Cheers,
david

>
> > I have been considering not going for 2.42 for Fedora 40, but we will
> > do this again one more time (hopefully it's the last time, but you
> > never know).
> >
> > > --
> > > _______________________________________________
> > > 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
> > > Do not reply to spam, report it: 
> > > https://pagure.io/fedora-infrastructure/new_issue
> > --
> > _______________________________________________
> > 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
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> _______________________________________________
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to