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 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 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. > > What the compiler outputs by default is merely one aspect of this > problem, the gcc wrapper is doing the right thing. > > You can easily set this up on the Debian build system sparc machines > by having the shell environment startup through "sparc32" when > a certain hostname is used. For example, foo-32 as the hostname > would cause this to happen. So use that hostname to build "sparc" > 32-bit packages, and use a non-environment-changing hostname in order > to build 64-bit sparc packages. This idea is about about 8 years > old. :-) > > This is needed _ANYWAYS_ to get the uname output to be correct for > 32-bit sparc builds. It prints out "sparc64" otherwise, and that makes > configure and other auto tools do the wrong thing. > > Consider this. When you build or bootstrap gcc, if "uname" outputs > "sparc64" you will not get a successful gcc bootstrap unless the compiler > outputs 64-bit code by default, requiring that "CC" gets changed to add > "-m64" to the command line is more than madness. > > The gcc bootstrap is the litmus test of correct default code type > generation behavior. > > 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] >
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]