This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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):
> 
>  sparcv9-*-solaris2*)
>    echo "sparcv9 is obsolete, use sparc64-*-solaris2* instead ; exit 1;;
>  sparc64-*-solaris2*)
>    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.

	Rainer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]