Re: HPPA and Squeeze
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
> Luk Claes schrieb:
> > Matthias Klose wrote:
> >> Grant Grundler schrieb:
> >>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
> >>>> Grant Grundler wrote:
> >
> >>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> >
> >>>>> http://lists.debian.org/debian-release/2009/04/msg00303.html
> >>>> Note that it's wrong to assume we will come with the answers.
> >>> I was expecting a summary of specific issues from an organization
> >>> that claims to operate transperently. The hand waving is easy. But
> >>> doesn't resolve problems and doesn't meet my expectation of an "open"
> >>> organization that I've donated money, time, and materials to.
> >> +1. dropping hppa as a release architecture was not communicated by the release
> >> team at all. I did spend some time to get gcj / default-jdk working on hppa,
> >> and some money (buying a new disk for a hppa machine) to help this port. The
> >> time and the money could have spent better, if d-r would have better
> >> communicated about their intent.
> >
> > There are issues with the hppa port where the release team considered
> > dropping it since 2005 communicated to the porter list...
> >
> >> hppa is not in a good shape, but there are other architectures which are not
> >> better (sparc, mips*) from a toolchain point of view. what about these?
> >
> > I'm not aware of current toolchain issues on sparc and the issues on
> > mips* still seem to be manageable, no?
>
> sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests
> to move to v9 optimization by default, which requires some work in the compiler.
> I don't plan to update this for upcoming GCC versions, and there's no interest
> by upstream to help with this kind of setup. You can't buy v8 software for years
> now, but afaik all our machines run 64bit kernels. Maybe it's time to
> acknowledge this, remove sparc from the list of release architectures and go on
> with sparc64?
Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
where the pros of the added registers overcome the cons of bigger
pointers. In other words, 64 bits code is slower, fatter and more memory
hungry than 32 bits code on sparc.
Mike
Reply to: