[PATCH] update config/* scripts, add support for riscv

[Qian Yun]

The patch is big, so I post it at:
https://github.com/fricas/fricas/pull/181

I tried to build fricas on riscv (via qemu, the performance
is surprisingly good, I built fricas-1.3.11 with sbcl with
4 cores taking less than 20 minutes.), it failed because the
platform is not recognized. After updating config/*,
the build succeeds except for one problem, sbcl can't compile
"|sockGetStringFrom|". (should be a sbcl bug.)

I nullified that function and build finishes, all tests passed.

- Qian

[Waldek Hebisch]

On Tue, Sep 24, 2024 at 09:59:43PM +0800, Qian Yun wrote:
> The patch is big, so I post it at:
> https://github.com/fricas/fricas/pull/181
>
> I tried to build fricas on riscv (via qemu, the performance
> is surprisingly good, I built fricas-1.3.11 with sbcl with
> 4 cores taking less than 20 minutes.), it failed because the
> platform is not recognized.

I now tried on a Risc-V machine using ecl (ATM do not have
sbcl there). Build works if one explicitly says 'riscv-linux-gnu'.
AFAICS it should work when one only updates 'config.guess'.
And when one adds on top of your patch the attached patch.

I would prefer to add this extra patch, as otherwise we
get the silly 'unknown' on most machines.

BTW: Debian installs programs without this part, building from
unmodified Gnu sources adds it, so Debian must have something
equivalent.

--
Waldek Hebisch

[Qian Yun]

On 11/28/24 9:50 AM, Waldek Hebisch wrote:
> On Tue, Sep 24, 2024 at 09:59:43PM +0800, Qian Yun wrote:
>> The patch is big, so I post it at:
>> https://github.com/fricas/fricas/pull/181
>>
>> I tried to build fricas on riscv (via qemu, the performance
>> is surprisingly good, I built fricas-1.3.11 with sbcl with
>> 4 cores taking less than 20 minutes.), it failed because the
>> platform is not recognized.
>
> I now tried on a Risc-V machine using ecl (ATM do not have
> sbcl there). Build works if one explicitly says 'riscv-linux-gnu'.
> AFAICS it should work when one only updates 'config.guess'.

But do you agree to update the other files as well?

> And when one adds on top of your patch the attached patch.

I guess it also builds fine without your patch?

> I would prefer to add this extra patch, as otherwise we
> get the silly 'unknown' on most machines.

Your patch also removes "-pc-"?

I would suggest to keep in sync with upstream, but if you insist...

- Qian

[Waldek Hebisch]

On Thu, Nov 28, 2024 at 10:49:26AM +0800, Qian Yun wrote:
> On 11/28/24 9:50 AM, Waldek Hebisch wrote:
> > On Tue, Sep 24, 2024 at 09:59:43PM +0800, Qian Yun wrote:
> >> The patch is big, so I post it at:
> >> https://github.com/fricas/fricas/pull/181
> >>
> >> I tried to build fricas on riscv (via qemu, the performance
> >> is surprisingly good, I built fricas-1.3.11 with sbcl with
> >> 4 cores taking less than 20 minutes.), it failed because the
> >> platform is not recognized.
> >
> > I now tried on a Risc-V machine using ecl (ATM do not have
> > sbcl there). Build works if one explicitly says 'riscv-linux-gnu'.
> > AFAICS it should work when one only updates 'config.guess'.
>
> But do you agree to update the other files as well?

Yes.

> > And when one adds on top of your patch the attached patch.
>
> I guess it also builds fine without your patch?

I think so.

> > I would prefer to add this extra patch, as otherwise we
> > get the silly 'unknown' on most machines.
>
> Your patch also removes "-pc-"?

Yes, for consistency. Both "unknown" and "pc" are essentially
meanigless.

> I would suggest to keep in sync with upstream, but if you insist...

I think shorter names are important. I do not know why GNU folks
use such song names, but Debian practice shows that shorter
names work even for programs that make more use of info
contained in the names than we do (we just need a part of name
that will not clash with part for other systems).

--
Waldek Hebisch

[Qian Yun]

On 11/28/24 7:17 PM, Waldek Hebisch wrote:
>
>> I would suggest to keep in sync with upstream, but if you insist...
>
> I think shorter names are important. I do not know why GNU folks
> use such song names, but Debian practice shows that shorter
> names work even for programs that make more use of info
> contained in the names than we do (we just need a part of name
> that will not clash with part for other systems).
>

Okay. I've committed my patch. And you can commit your
patch separately now (so that it will be easier to apply
it again when we update config.sub in the future.)

- Qian