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

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.  At least the src repository will have to
be updated at the same time as this new upstream config.sub is imported
into the gcc tree.

> access.  But zapping sparcv9 from gcc is still on my list (at this
> point it'll be after the summit.)  Assuming someone else steps up for
> the other packages, are we agreed then?  Rainer?

Neither do I have src write access nor the time for such an endavour.  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.  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.


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