This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Document Sparc64 configuration
Kaveh R. Ghazi writes:
> I have no plans to modify config.sub. What I intend to do is obsolete
> sparcv9 in config.gcc like so (pseudo-code):
> echo "sparcv9 is obsolete, use sparc64-*-solaris2* instead ; exit 1;;
> normal sparc64-solaris stuff
> and then zap all references to sparcv9 in the gcc directory (except
> for upsteam files which I won't touch.) This will steer people to
> configure gcc-3.4 as sparc64.
I don't like this gcc-only approach. I think the goal should be for all
GNU packages to behave consistently, and that would mean having one common
canonical name for 64-bit SPARC configurations and using it in all relevant
tools (like gdb, binutils, gas, ld, ...). Rejecting sparcv9-*-solaris2* in
gcc only while it may still be required for some of the others is a
disservice to the users (and may break uberbaum builds).
Since config.gcc deals with canonical names anyway, I think it makes much
more sense to continue accepting the alias forms and standardize on a
single canonical form (be that sparcv9 or sparc64). This requires some
modification to config.sub. I think the testsuite deals with canonical
names only, not with the target alias the user chose.
> Agreed. In choosing between the two myself, since every other OS uses
> sparc64, I felt it was more conforming and simple to pick sparc64 for
> solaris2 also rather than be the odd man out.
As stated, sparcv9 is the canonical name for the architecture, even if
Linux and *BSD chose otherwise. If sparc64 is chosen for the *canonical*
form, so be it, but I see no reason for a wholesale rejection of the old
form if there's another way to deal with the situation.
> What is your reason for wanting to extend this process? I don't quite
> get why you reference $libdir and $target_alias above or why you think
> people will want/need to continue to use the sparcv9 alias form.
> Would you please clarify for me?
Because they are used to this form for years, and I don't think it's
appropriate for gcc to unilaterally obsolete it, while it is still valid
(or even required) for other packages. I'm referring to
$libdir/gcc-lib/$target_alias because this contains the configuration name
in a user-visible form (e.g. in gcc -v output), be it
sparcv9-sun-solaris2.8 or whatever the user chose at configure time.