Re: Avoid endian.h include in MIPS string functions

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Sun, 6 May 2012, Mike Frysinger wrote:

> On Sunday 06 May 2012 01:55:04 Maciej W. Rozycki wrote:
> > On Thu, 26 Apr 2012, Joseph S. Myers wrote:
> > > Similar to a recent SH libc change, I've applied this patch to avoid MIPS
> > > string .S functions including <endian.h> and getting errors from C source
> > > code from that header.
> > 
> >  Hmm, <endian.h> is a user header and I could imagine software to rely on
> > it even in handcoded assembly.  And it used to work just fine.  Are you
> > sure the problematic stuff in <endian.h> or pulled by it shouldn't be
> > wrapped into:
> > 
> > #ifndef __ASSEMBLER__
> > 
> > or suchlike instead?
> 
> a patch was posted to do that, but no one responded :/
> 
> http://sourceware.org/ml/libc-alpha/2012-04/msg01141.html

 So I've had a more thorough look into it and it seems the breakage is 
inherited from BSD compatibility and <endian.h> is still usable from 
assembly sources unless __USE_BSD is in effect -- i.e. _BSD_SOURCE or 
_GNU_SOURCE, etc. -- and we build with _GNU_SOURCE so we are hit by this 
problem.  I find it odd that defining _GNU_SOURCE regresses functionality, 
but given the maintainers do not bother, I guess it'll have to stay.

 __ASSEMBLER__ is a standard GCC's cpp macro, even documented in the cpp 
manual, and I don't think our library supports any non-GCC systems these 
days anymore, so I don't really get what might be wrong with using that to 
guard headers.

  Maciej