--- "David S.Miller" <[EMAIL PROTECTED]> wrote:
> People can't wrap their brain around how to build a sparc64
> kernel often right now anyways, making things sparc32 by
> default isn't going to change that.
>
> The most common error is simply not having a 64-bit libc
> installed, which is needed t
libncurses5 for sparc64 has been around for a long time. I don't use
anything other than menuconfig, so I can't speak for other ui interfaces.
> There also does not exist the necessary 64-bit versions of the
> graphical libraries needed to use the graphical kernel configurator.
> But one can overr
On 05/24/05 05:38:58PM -0700, David S.Miller wrote:
> From: "Jim Crilly" <[EMAIL PROTECTED]>
> Date: Tue, 24 May 2005 14:42:27 -0400
>
> > True, but building kernels on sparc64 wasn't terribly fun for me the last
> > time I tried it either so I decided it wasn't worth it and just stuck with
> > th
From: Ben Collins <[EMAIL PROTECTED]>
Date: Tue, 24 May 2005 14:29:16 -0400
> And what about building kernels? They will by default be building
> sparc32 kernels. That's the most likely place for this to be a
> problem.
People can't wrap their brain around how to build a sparc64
kernel often righ
From: "Jim Crilly" <[EMAIL PROTECTED]>
Date: Tue, 24 May 2005 14:42:27 -0400
> True, but building kernels on sparc64 wasn't terribly fun for me the last
> time I tried it either so I decided it wasn't worth it and just stuck with
> the Debian kernel images.
Amusing as I do all of the sparc64 ker
On 05/24/05 02:29:16PM -0400, Ben Collins wrote:
> On Tue, May 24, 2005 at 01:32:54AM -0400, Jim Crilly wrote:
> > > >
> > > > Make the login environment be sparc32 by default. Doesn't that
> > > > solve the problem? And for die-hard 64-bit people like me they
> > > > can undo this via some conf
On Tue, May 24, 2005 at 01:32:54AM -0400, Jim Crilly wrote:
> > >
> > > Make the login environment be sparc32 by default. Doesn't that
> > > solve the problem? And for die-hard 64-bit people like me they
> > > can undo this via some configuration mechanism.
> > >
> > > It is one option.
> >
>
> >
> > Make the login environment be sparc32 by default. Doesn't that
> > solve the problem? And for die-hard 64-bit people like me they
> > can undo this via some configuration mechanism.
> >
> > It is one option.
>
> That's probably too ugly for some ppl. Then we'll have to answer the
> que
On Mon, May 23, 2005 at 07:27:22PM -0700, David S.Miller wrote:
> From: Ben Collins <[EMAIL PROTECTED]>
> Date: Mon, 23 May 2005 20:21:57 -0400
>
> > But (and this but is for David), that means users can't simply do
> > "apt-get source foo; cd foo-1.1; dpkg-buildpackage" and get the same build
> >
From: Ben Collins <[EMAIL PROTECTED]>
Date: Mon, 23 May 2005 20:21:57 -0400
> But (and this but is for David), that means users can't simply do
> "apt-get source foo; cd foo-1.1; dpkg-buildpackage" and get the same build
> they got from us, which is a consistency Debian needs. Maintainers trying
>
You're right. Didn't get down that far. As far as I'm concerned, the
default 64-bit is the right thing. But it's hard to convince long time
users that a machine that is 99% 32-bit userspace, should compile 64-bit
binaries by default, when 99% of the time, those same people are going to
want 32-bit.
The other alternative is to "touch /etc/disable_64_gcc
On Sat, May 21, 2005 at 04:05:21PM -0700, David S. Miller wrote:
> On Sat, 21 May 2005 14:06:52 +0200
> Falk Hueffner <[EMAIL PROTECTED]> wrote:
>
> > this bug has been open for quite some time as "important". Can some
> > sparc people please
From: [EMAIL PROTECTED]
Date: Mon, 23 May 2005 13:24:18 -0700
> The other alternative is to "touch /etc/disable_64_gcc
Sure, but in the mail you are specifically replying to I stated:
> > Also, /etc/disable_64_gcc is a workaround and should not be there
> > by default as it is now, especially on
David S. Miller wrote:
[snip]
> This is not a bug, it should be closed. On sparc64, gcc should emit
> 64-bit code by default. If you want 32-bit code emitted on a sparc64
> system you have exactly two options 1) add -m32 to the command line
> or 2) run your build in a "sparc32 bash" environment.
From: Thiemo Seufer <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 01:37:50 +0200
> David S. Miller wrote:
> [snip]
> > This is not a bug, it should be closed. On sparc64, gcc should emit
> > 64-bit code by default. If you want 32-bit code emitted on a sparc64
> > system you have exactly two options
On Sat, 21 May 2005 14:06:52 +0200
Falk Hueffner <[EMAIL PROTECTED]> wrote:
> this bug has been open for quite some time as "important". Can some
> sparc people please comment on it?
This is not a bug, it should be closed. On sparc64, gcc should emit
64-bit code by default. If you want 32-bit c
Hi,
this bug has been open for quite some time as "important". Can some
sparc people please comment on it?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: gcc
Version: 4:3.3.3-3
Severity: important
[ Marked as important since this vile wrapper has permeated testing
already. ]
/usr/bin/gcc on the sparc architecture is really a link to a C wrapper
that calls gcc-3.3 with either -m64 or -m32 depending on the native
architecture, sparc64 or sp
18 matches
Mail list logo
