Hi, 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. 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 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. The change that causes this is from 2019-01-03, commit 5fe51ffd1b2933fce914b0be5a651ee7ec21e6d2 . I kindly suggest to revert this change. Bruno _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
