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

[Bruno Haible]

Alexey Dokuchaev wrote in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51144> and
<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00018.html>:

> > >Ports framework does several things which affect GNU configure
> > >scripts, particularly, it replaces build-aux/config.guess file
> > >with our own, where host/build tuples are derived from.
> > >
> > >x86_64 is spelled as amd64 in FreeBSD
...
> 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
                ;;

The rationale for this canonicalization is that on the C preprocessor
level, significant synonyms exist (see [1] for the list), and this has
caused many portability issues over time. So, at the autoconf level,
the GNU project has decided to canonicalize the elements of $host.
Linux prefers x86_64, FreeBSD prefers amd64, Windows prefers x64,
and so on. The canonicalization
1) allows the GNU packages to recognize just one (x86_64) instead of
   multiple ones,
2) allows GNU packages that include arch-dependent files (e.g.
   GNU gmp, GNU lightning, GNU libffcall) to name these files consistently.
   Not asm-x86_64.c in one package and asm-amd64.c in another package.

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.

You can replace the config.guess script before building a package
in the FreeBSD ports collection. But when it's a GNU package you should
better make sure that this replacement script produces the same results
as the GNU config.guess does.

The same holds for the non-GNU non-FreeBSD packages that use Autoconf:
If you force non-GNU-canonical names on them, they may curse the GNU
build system, but in fact the culprit (= origin of the issue) would
still be the choices made in the FreeBSD ports build system.

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.

Btw, a similar problem exists for the aarch64 / arm64 CPU type.
'aarch64' is the name chosen by the GCC people, whereas 'arm64' is the
name chosen by Linux [2] and by Debian [3]. You need to obey the
canonicalization in effect at the level at which you are working;
at the $host_cpu level you should expect to see 'aarch64', never 'arm64' —
because passing --host=arm64-... is wrong.

Bruno

[1] https://sourceforge.net/p/predef/wiki/Architectures/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch?h=v5.0
[3] http://ftp.debian.org/debian/dists/Debian10.11/main/