This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: biarch gcc
- From: Michael Matz <matz at suse dot de>
- To: Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: Andreas Jaeger <aj at suse dot de>, <gcc at gcc dot gnu dot org>
- Date: Wed, 13 Aug 2003 00:48:37 +0200 (CEST)
- Subject: Re: biarch gcc
Hi,
On Tue, 12 Aug 2003, Peter Bergner wrote:
> > The Glibc headers for sparc, s390 and x86_64 were written with that in
> > mind and do not have any problems that I'm aware of. What problems
> > exactly do you have?
>
> I believe Alan was talking about kernel headers here and not GLIBC headers.
> The stub workaround Alan speaks of is the same workaround you (ie, SuSE) used
> on SLES8. For example:
>
> cannon% cat /usr/include/asm/unistd.h
> #ifndef __PPC_ASM_STUB__UNISTD_H__
> #define __PPC_ASM_STUB__UNISTD_H__
> #ifdef __powerpc64__
> #include <asm-ppc64/unistd.h>
> #else
> #include <asm-ppc/unistd.h>
> #endif
> #endif
Well, having and maintaining such stub headers is a small cost compared to
the advantage of having a real biarch compiler, which should be done, like
it's done already for many other 32/64 platforms. In fact I'm not
entirely sure, about what Alan was complaining, but at least the
difference between 32 and 64 bit in header files is no reason to not build
a biarch compiler. About the suggestion of only creating a biarch
compiler, when --enable-biarch is given I'm also not entirely sure. What
is the difference to not fulfilling the prerequisites? Better
error-messages from configure? That would be good, but I felt Alan was
also suggesting this for other reasons I'm not getting?
Ciao,
Michael.