From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5406 invoked by alias); 19 May 2012 18:33:22 -0000 Received: (qmail 5396 invoked by uid 22791); 19 May 2012 18:33:21 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (78.24.191.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 19 May 2012 18:33:07 +0000 Received: from localhost.localdomain ([127.0.0.1]:48356 "EHLO localhost.localdomain" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1901760Ab2ESSdF (ORCPT ); Sat, 19 May 2012 20:33:05 +0200 Date: Sat, 19 May 2012 18:33:00 -0000 From: "Maciej W. Rozycki" To: Mike Frysinger cc: libc-ports@sourceware.org, "Joseph S. Myers" Subject: Re: Avoid endian.h include in MIPS string functions In-Reply-To: <201205060229.55306.vapier@gentoo.org> Message-ID: References: <201205060229.55306.vapier@gentoo.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00115.txt.bz2 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 and getting errors from C source > > > code from that header. > > > > Hmm, 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 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 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