bug#51144: GNU grep 3.7 fails to build on FreeBSD

[Alexey Dokuchaev]

On Sun, Oct 17, 2021 at 11:20:12PM +0200, Bruno Haible wrote:
> Alexey Dokuchaev wrote in
> ...
> > All we do is
> > use our pre-built templates for config.{guess,site,sub} and pass the
> > --build=amd64-portbld-freebsd$(version) argument to configure scripts
> > if they are generated by GNU autotools.
> 
> This is a recipe for major hassle. The output of config.{guess,sub}
> is a *canonicalized* triple. See this comment in config.sub:
> 
>   # The goal of this file is to map all the various variations of a given
>   # machine specification into a single specification in the form:
>   #       CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
>   # or in some cases, the newer four-part form:
>   #       CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
> 
> and later:
> 
>         # Here we normalize CPU types irrespective of the vendor
>         amd64-*)
>                 cpu=x86_64
>                 ;;

Hmm, there's no such normalization code in our /usr/ports/Templates/config.sub
with timestamp='2018-05-24'.

> You can architecture the FreeBSD ports collection and its build system
> in the way you like. But you cannot expect dozens of GNU packages to
> support a different name for a CPU than the canonical name that GNU
> picked 18 years ago:
> 
>     2003-05-09  Andreas Jaeger  <aj@suse.de>
> 
>       * config.sub (maybe_os): Add alias amd64 for x86_64.

I wonder why it's not in our template if it's from 2003.

> Paul Eggert asked:
> > > would you also consider adding "amd64" as a synonym to "x86_64" in
> > > that switch/case check?
> >
> > Yes I suppose we could do that. Bruno, what do you think? You wrote most
> > of those "x86_64"s.
> 
> A firm "no!" from my part.

Fair enough; I guess we can live with local patches to configure for our
diffutils and grep ports (for now).

./danfe