This is the mail archive of the mailing list for the glibc 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: [Patch] Fix MIPS build failure caused by -Werror=undef

On Tue, 2015-02-17 at 19:58 +0000, Maciej W. Rozycki wrote:

>  There's clearly nothing Linux specific there although one might ask which 
> of the two of __MIPSEB vs __MIPSEB__ is the "traditional" macro we might 
> want to keep.  Or maybe _MIPSEB even.  I'm not sure offhand and clearly 
> current GCC defines all at a time.
>  Also I wonder if sanity checks like:
> #if defined (__MIPSEB) && defined (__MIPSEL)
> # error "Both __MIPSEB and __MIPSEL, endianness configuration problem?"
> #elif defined (__MIPSEB)
> # define __BYTE_ORDER __BIG_ENDIAN
> #elif defined (__MIPSEL)
> #elif
> # error "Neither __MIPSEB nor __MIPSEL, endianness configuration problem?"
> #endif
> would make sense here too, to catch issues early on in case someone does 
> something silly with `-D' or `-U'.
>   Maciej

I wonder if we should check here or if we should check in the shared
src/glibc/string/endian.h file.  We could verify that after including a
system specific bits/endian.h, __BYTE_ORDER is defined to either

Maybe change this check in src/glibc/string/endian.h to have a '#else
#error' clause.  Is it ever legal to not define __BYTE_ORDER?

# define __LONG_LONG_PAIR(HI, LO) LO, HI
# define __LONG_LONG_PAIR(HI, LO) HI, LO

Steve Ellcey

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