From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5885 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: the definition of (u)int64_t with gcc -m32 in stdint.h Date: Thu, 21 Aug 2014 12:47:42 -0400 Message-ID: <20140821164742.GL12888@brightrain.aerifal.cx> References: <20140821171511.06869699@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1408639701 16365 80.91.229.3 (21 Aug 2014 16:48:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 16:48:21 +0000 (UTC) Cc: musl@lists.openwall.com To: Khem Raj Original-X-From: musl-return-5891-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 21 18:48:12 2014 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 1XKVWp-0004f3-O8 for gllmg-musl@plane.gmane.org; Thu, 21 Aug 2014 18:47:59 +0200 Original-Received: (qmail 16313 invoked by uid 550); 21 Aug 2014 16:47: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 16302 invoked from network); 21 Aug 2014 16:47:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5885 Archived-At: On Thu, Aug 21, 2014 at 08:25:40AM -0700, Khem Raj wrote: > > so on musl it is 'long' but on uclibc its 'long long int'. > > > > That explains why it works on uclibc but not on musl. > > > > Now, what is the proper way to fix it? Preferible without replacing > > all (u)int*_t all places in xen code. I doubt upstream will accept that. > > > > Do we support multilib with musl yes ? With separate include dirs for each, yes. But not using the same includes. glibc treats i386 and x86_64 (and x32) basically as a common arch, at least as far as headers are concerned, with a lot of the header content being determined at compile time via __WORDSIZE or similar. musl treats them all as separate. Presumably gcc can be configured, at least via the spec file if nothing else, to use a different include dir when -m32 is passed. Rich