From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3444 Path: news.gmane.org!not-for-mail From: "Anthony G. Basile" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: gnulib cross-compiling issue with musl Date: Thu, 20 Jun 2013 12:08:51 -0400 Message-ID: <51C32913.9050603@opensource.dyc.edu> References: <20130618170305.GA30936@brightrain.aerifal.cx> <51C09BD9.8000503@cs.ucla.edu> <20130618180755.GV29800@brightrain.aerifal.cx> <51C0A7D2.4020605@cs.ucla.edu> <20130618184224.GW29800@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1371744480 30658 80.91.229.3 (20 Jun 2013 16:08:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Jun 2013 16:08:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3448-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 20 18:08:01 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UphOz-0001WA-3P for gllmg-musl@plane.gmane.org; Thu, 20 Jun 2013 18:08:01 +0200 Original-Received: (qmail 24240 invoked by uid 550); 20 Jun 2013 16:07:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24232 invoked from network); 20 Jun 2013 16:07:59 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Thunderbird/17.0.6 In-Reply-To: <20130618184224.GW29800@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3444 Archived-At: On 06/18/2013 02:42 PM, Rich Felker wrote: > On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote: > > I'm saying that musl intentionally does not provide any macros to > identify itself. Changing this to help gnulib do one correct thing > would not be worth dealing with all the incorrect usages it would lead > to. And I'm confident that presence of such a macro would lead to lots > of bugs in lots of applications, and to people blaming us for changing > things when such incorrect applications break, on the basis of all the > requests we have received from users for a __MUSL__ macro. In every > case, we have been able to recommend clean portable solutions that did > not involve hard-coding assumptions about musl. > Hi Rich, I see your point wrt no __MUSL__ macro, but in practice this is a tough one to live with. It is not just gnulib that makes assumptions about libc, although needing the internals of FILE is extreme given that implementation details are subject to change. Most of what I'm hitting porting Gentoo over are assumptions about what is provided or where it is provide or how it is provided (and standards be damned), and I can't play the usual game of #ifdef __MUSL__ as I did for uclibc. I know you might respond with "that's what build systems are for", but ... ouch ... Not to derail, but gnulib was the my first experience of a sequence. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197