At Wed, 6 Aug 2003 10:27:00 -0400,
Ben Collins wrote:
> On Wed, Aug 06, 2003 at 09:08:15AM +0200, Harald Nordg?rd-Hansen wrote:
> > Ben Collins <firstname.lastname@example.org> writes:
> > > Not a bug. Current gcc-3.2/gcc-3.3 on sparc is geared toward a default
> > > v8 hwmul target (e.g. real sun4m's and up). The reason being that the
> > > old v7/v8softmul was bringing performance down noticably (and I mean
> > > visually being able to measure small task differences).
> > >
> > > I announced probably 6 months or more ago that this would happen, so it
> > > should be no surprise.
> > I would suggest that this is flagged in the packages as well, as a
> > user I'm sorry, but I just don't follow the sparc lists.
> > > sun4c and sun4m-softmul owners should stick with woody.
> > Why? A simple thing like flagging in gcc and(/or?) libc6 on upgrade
> > that they now require kernel 2.4.21 or newer on some machines would be
> > sufficient. But when doing a simple upgrade of a box and suddenly
> > binaries start failing all over the place is certainly what I would
> > call a bug.
> > There are some of us out here that are just users of a platform.
> > Please, when doing this sort of changes do flag them in at least the
> > basic packages.
> It will be in the release notes.
We already dropped sun4c, and kernel 2.4.21 already supported hwmul
instruction using trap. Is it true?
If so, I think there are at least 3 different way to handle this bug:
(1) We should only close this bug.
(2) We reassign this bug to old sparc kernel package, and such
package should notify for sun4c users that "if you're sun4c user,
then you have to upgrade your kernel into 2.4.21".
(3) libc6 should check sun4c and kernel version, and warn "you should
use kernel 2.4.21 or later", and stops upgrade.
IMHO, (3) is easiest way to notify users and stop upgrading.