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: [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 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]