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

[Cedric Berger]

On 13.05.22 17:55, Joel Sherrill wrote:
> 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.

It's fixed, basically, for all 3 projects, if they would care to 
regenerate+release:

https://git.savannah.gnu.org/cgit/config.git/commit/?id=3c20dd431e06337a8b49d8bf791a6a19523a34a4

https://git.savannah.gnu.org/cgit/config.git/commit/?id=2593751ef276497e312d7c4ce7fd049614c7bf80

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

That makes sense.

> 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.

No probem, I understand and it makes sense to put upstream, but again, 
in that particular case, the real problem (autoconf) is already fixed 
upstream.

Cedric