Bug#251149: Bug #251149: gcc wrapper for sparc is chronically broken
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.
This is a good argument, but as all Debian developers should know, we
should take technical correctness over anything. Having a 64-bit machine
compile 64-bit by default is technically correct.
When "uname -m" reports "sparc64", we should get sparc64 binaries from
the compiler. There are tons of work arounds in packages which _correctly_
assumed that sparc64 meant 64-bit, to get them to instead do 32-bit (I
believe SSL is one of them, since it always tried to do v9 assembly for
sparc64 uname).
This is exactly why when I was running the sparc buildd's, I had the build
daemon invoking sparc32 for build commands, which is what it should do.
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
to fix bugs on sparc in their packages that log in to one of our machines
shouldn't have to worry about this subtlety either.
So we have to have a correct toolchain, but we also need to make our build
system consistent across invocations and users and machines. How do we do
this? I'm not sure. We might need to add something into our dpkg-dev
system. That's not such a hard thing to do, but it should be easy for
someone to disable it in case (like I've done before), someone really does
want to build 64-bit packages.
On Mon, May 23, 2005 at 02:30:19PM -0700, David S.Miller wrote:
> From: bcollins@debian.org
> 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 your build machines. So I
> > > highly recommend that the build machine environment setup I
> > > described above is implemented.
> > >
> > > I'm going to be making GCC do this in the vanilla gcc sources by
> > > default, I've already convinced the other Sparc backend
> > > maintainers that it is the absolute right thing to do. And it
> > > won't be checking for the /etc/disable_64_gcc workaround file.
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Reply to: