This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: biarch gcc


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]