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 <a...@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/