Bug#251149: Bug #251149: gcc wrapper for sparc is chronically broken
On Sat, 21 May 2005 14:06:52 +0200
Falk Hueffner <falk@debian.org> 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.
Reply to: