[PATCH] ISL, MPC, MPFR: fix configuration issues on ARM64/Darwin host

[Joel Sherrill]

On Fri, May 13, 2022 at 10:42 AM Cedric Berger <cedric at precidata.com> wrote:

> On 13.05.22 17:25, Joel Sherrill wrote:
> > I think you are missing my point. I'm not opposed to the patches and
> > understand the need.
> >
> > The RTEMS Project tried putting patches in our git repos when the RSB
> > was new.  It did not improve our diligence in getting them upstream or
> > removing them from our git when no longer needed. Putting them in
> > tickets at RTEMS.org or upstream improved how diligent we were about
> > at least putting the patch into the right hands.
>
> Ok, I guess understand the need for a ticket on RTEMS.org.
>
> What I'm not sure is what to do upstream: just open a ticket on
> mpfr/isl/mpc that says "Please unslack and release a new version of your
> code, it doesn't work on the M1"?
>

lol. Probably just to politely remind them that their releases need a poke.

If it's not fixed in their development source, then that's a big reason to
poke and provide the patch.

But the ticket on our side can give a log of the effort to get it dealt
with
upstream.

This also shows that we need to clean some patches out of the RSB
and RTEMS tools.

Sorry for the lesson in how we have evolved our handling of
patches for upstream projects. It has evolved from back when
the project provided RPMs and they almost never got upstream
to having the RSB and putting them in our repos to now trying to
do the right thing in the beginning and posting them to the project
via their list, a ticket, or via actual merge. If you notice, we have a
pretty tight loop for getting patches into newlib and gcc. binutils
rarely has issues. gdb is slower but we do ok. We've just learned that
if you push on them while working on them, they tend to get merged
so a patch against tool version N is usually obsolete for N+1. The
alternative is updating the patches every release until we do the
right thing.

--joel

>
> Cedric
>
>
>