Re: canonical triple of SPARC/Solaris changed

[Rainer Orth]

Hi Bruno,

> With the newest config.guess, GNU libffcall 2.x no longer builds out of the
> box on SPARC / Solaris 10 with CC="cc -xarch=generic64 -O".
>
> The reason is that config.guess, which used to return 'sparc-sun-solaris2.10',
> now returns 'sparcv9-sun-solaris2.10'.
>
> 1) This is a regression. The platform exists for 20 years, and there is
>    no good reason to change the triple of ANY platform after it is in
>    production for more than 1 year.

if you'd read the patch submission, you'd know that there is indeed.
Besides, I'm not changing the triplet in general, just making more use
of a form of the Solaris/SPARC triplet that has been valid for many
years, since 1997 when Solaris 7 introduced SPARC V9 support to be exact.

> 2) There are already Autoconf macros for determining the ABI generated by
>    the compiler. And there are Autoconf macros for determining whether
>    the compiler generates 32-bit or 64-bit code. Such a macro is contained
>    in Gnulib, module 'host-cpu-c-abi':
>    
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/host-cpu-c-abi.m4

This may be true (although host-cpu-c-abi is buggy and the cause of your
current problem, as I'll show below), but the toolchain (gcc, binutils,
gdb, ...) has always relied on the configure triplets alone.  There's no
reason to change that now.

> 3) Different packages have different needs, in this area.
>
>    * Some package may only want to know whether sizeof (void*) == 4 or == 8.
>      Thus it will treat the two 32-bit ABIs on x86_64 (commonly denoted as
>      'i386' and 'x32') the same. Similarly on MIPS, where the 'o32' and 'n32'
>      ABIs both have sizeof (void*) == 4.
>
>    * Some package wants an ABI identifier, in order to know what kinds of
>      binaries can be linked together and what binaries cannot.
>      E.g. on x86_64, i386 libraries, x32 libraries, and x86_64 libraries
>      are mutually link-incompatible. So, for these kinds of packages, there
>      will be 3 possible answers on x86_64 systems.
>
>    * Some package (like GNU gmp) wants an ABI identifier that includes an
>      indication regarding the instruction set. For example, 'arm' has
>      armv5, armv6, armv7 (and many more) instruction sets.
>
>    * Some packages want to distinguish the 32-bit PowerPC ABI on Mac OS X,
>      the 32-bit PowerPC ABI on AIX, and the 32-bit PowerPC ABI on Linux and
>      *BSD OSes. Namely, packages that have hand-written assembly language
>      sources; the assembler pseudo-ops differ.
>
>    Since different packages have different needs in this area, it makes no
>    sense to try to put the result into the config.guess triple. Such an
>    approach will NEVER be able to satisfy the needs.
>
>    The only approach that makes sense is an Autoconf macro for each of
>    the purposes/needs.

While those uses and needs do exist, the change you complain about
didn't try to satify all those needs, just those of the toolchain, one
of the core users of configure triplets.

> The change that causes this is from 2019-01-03, commit
> 5fe51ffd1b2933fce914b0be5a651ee7ec21e6d2 .
>
> I kindly suggest to revert this change.

I don't think so, certainly not for the reason you cite.  Since you give
no details about the specifics of the breakage, I did some investigation
myself.  I've worked off libffcall 2.1, the latest release, since I felt
no inclination to build tons of cross compilers as seems to be required
for the git version.

libffcall 2.1 contains a version of config.guess that predates my
change.  If you try to configure and build it with

$ .../configure CC='gcc -m64' --build=sparcv9-sun-solaris2.11
$ make

it fails with

make[1]: *** No rule to make target 'avcall-sparcv9.lo', needed by 'avcall.lo'. 
 Stop.

As I said above, that configure triplet has been valid (and even
canonical) all along, together with several other variants of sparc*.

Some digging found that the gnulib macro from
gnulib-m4/host-cpu-c-abi.m4 you cite above is the culprit here: it
contains

    [case "$host_cpu" in
[...]
       sparc | sparc64 )
         # UltraSPARCs running Linux have `uname -m` = "sparc64", but the
         # C compiler still generates 32-bit code.
         AC_COMPILE_IFELSE(
           [AC_LANG_SOURCE(
              [[#if defined __sparcv9 || defined __arch64__
                 int ok;
                #else
                 error fail
                #endif
              ]])],
           [gl_cv_host_cpu_c_abi=sparc64],
           [gl_cv_host_cpu_c_abi=sparc])
         ;;

And here's your bug: as you can see in config.sub, there are a couple of
valid and canonical forms of the cpu part for sparc:

                        | sparc | sparc64 | sparc64b | sparc64v | sparc86x | 
sparclet \
                        | sparclite \
                        | sparcv8 | sparcv9 | sparcv9b | sparcv9v | sv1 | sx* \

If you change the macro above to accept not only the sparc and sparc64
forms you chose to support (for whatever reason), but either that whole
set or even simpler, sparc*, your problem goes away.

All this was with older config.guess/config.sub already.  To test it, I
just hacked that change into configure, dropped the current config.guess
and config.sub into build-aux and now all builds and tests of libffcall
2.1 pass for 32 and 64-bit Solaris/SPARC (gcc -m64 with no --build
option, --build sparcv9-sun-solaris2.11, and --build sparc64-sun-solaris2.11).

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University