Hi Rainer,
> 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.
Correct. That's the error I encountered when using a config.guess from
a couple of days ago.
> 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.
Sorry, but I cannot use this approach in GNU libffcall:
* Some of the CPU name variants don't have the same instruction sets as
the main variant. For example, 'powerpc' code will not run on a 'powerpcspe'
machines. And 'mips64' code will not run correctly on 'mips64le' machines.
Maybe the same is true for some 'sparc' variants; I don't know.
If I were to follow your advice, people would see that libffcall compiles
fine on their machine and then be disappointed that the code crashes.
With the approach I've chosen, people see a build-fails situation and
report it on the bug tracker, _without_ getting the impression that the
package is unreliable.
* Therefore I'm using the approach that I test on specific platforms, and
refrain from pretending to support anything that I cannot test. (I believe
GCC uses the same approach.)
So far, all SPARC-based platforms I tested (Linux/sparc, Solaris/sparc,
NetBSD/sparc) all return 'sparc' or 'sparc64' as the $host_cpu. None returns
'sparcv9', 'sparclite', 'sparc86x', or similar.
When a new platform arises that has a new cpu, maybe 'sparct6' or so, and
someone has tested that libffcall builds and runs fine with it, I add this
cpu to the various conditionals.
The way I work with these configure triplets just breaks down when the
triplet of an existing platform changes. If you had picked 'sparc64'
instead of 'sparc', libffcall would not have had problems, because
'sparc64' is the $host_cpu on Linux/sparc64. But other packages (maybe
GMP) still might have had problems.
> Besides, I'm not changing the triplet in general, just making more use
> of a form of the Solaris/SPARC triplet
The patch changed the triplet of an existing platform.
The config.{guess,sub} combination and its documentation does not formally
define a range of triplets (e.g. "sparc*-*-solaris*") per platform. Even if
such a formal specification existed, I doubt that it would make sense to
use it in GNU libffcall, because I don't know about all the possible variants
of sparc CPUs, thus this would contradict my "support only what you have
tested" approach.
> > 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.
https://lists.gnu.org/archive/html/config-patches/2019-01/msg00000.html
mentions GCC as motivation. By the arguments in my previous mail it is clear
that the proper place for this code
if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
if (echo '#ifdef __sparcv9'; echo IS_64BIT_ARCH; echo '#endif') | \
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
grep IS_64BIT_ARCH >/dev/null
then
SUN_ARCH=sparcv9
fi
fi
is the configure.ac script of GCC or some .m4 file or helper script used by
this configure.ac script.
> the toolchain (gcc, binutils,
> gdb, ...) has always relied on the configure triplets alone. There's no
> reason to change that now.
This is not true. gcc-8.2.0/gcc/config.host tests the linker version to
determine host_ppc_relax_xmake_file.
This script could also run the compiler, to detect whether it is 64-bit.
(Unless maybe that conflicts with the determination of cpu_is_64bit in
config.gcc?)
Bruno
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
