This is the mail archive of the 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

 > From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
 > Kaveh R. Ghazi writes:
 > > Someone else will have to do the other packages, I don't have write
 > But is this really feasible?  If config.sub is changed to canonicalize
 > e.g. sparcv9-sun-solaris2 to sparc64-sun-solaris2, other packages relying
 > on the former variant will break.

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.

 > If the goal is to have only a single canonical name for 64-bit
 > SPARC instead of the current two (sparcv9 and sparc64), this is
 > certainly helpful and simplifies maintenance.

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.

 > I'm still quite unhappy about the proposed choice
 > of sparc64 in this role for the reasons stated (and would rather prefer
 > sparcv9 here), but could (grudgingly) live with such a decision since as
 > far as I can see users can still use the sparcv9 alias form and that will
 > remain user visible (e.g. in the $libdir/gcc-lib subdirectory, which uses
 > $target_alias).  The sparcv9 variant will probably have to remain in
 > end-user documentation for quite some time.
 > 	Rainer

Except for noting sparcv9 is obsolete and that one should use
sparc64 instead, I planned on killing all sparcv9 references (or
renaming sparcv9 to sparc64 as appropriate.)

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?

Kaveh R. Ghazi

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