From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3111 Path: news.gmane.org!not-for-mail From: Zvi Gilboa Newsgroups: gmane.linux.lib.musl.general Subject: Re: Request for ideas on arch-specific musl-gcc specfile additions Date: Mon, 15 Apr 2013 00:31:34 -0400 Message-ID: <516B82A6.2020800@eservices.virginia.edu> References: <20130415013154.GA7440@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 1366000307 24946 80.91.229.3 (15 Apr 2013 04:31:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 04:31:47 +0000 (UTC) To: Original-X-From: musl-return-3115-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 15 06:31:51 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 1URb54-0004vV-Av for gllmg-musl@plane.gmane.org; Mon, 15 Apr 2013 06:31:50 +0200 Original-Received: (qmail 5496 invoked by uid 550); 15 Apr 2013 04:31:48 -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 5482 invoked from network); 15 Apr 2013 04:31:48 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 In-Reply-To: <20130415013154.GA7440@brightrain.aerifal.cx> X-Originating-IP: [172.25.251.153] Xref: news.gmane.org gmane.linux.lib.musl.general:3111 Archived-At: On 04/14/2013 09:31 PM, Rich Felker wrote: > Right now, musl-gcc has problems on at least a few archs: > > - powerpc: it does not setup the right secure-plt options for dynamic > linking. > > - mips: gcc's internals on mips expect the -EL and -EB options to work > for selecting endianness, but they're not real options; they're > created by the specfile > > - any arch with 32/64-bit variants: if -m32 or -m64 was used building > musl, it should get added to the specfile for musl-gcc. > > I'm looking for a clean approach to fixing this. Certainly the > configure script could just generate one or more extra variables that > get stored in config.mak and substituted into the specfile, but I'd > rather avoid having essential logic like this in configure, as it > makes it difficult for anybody who wants to generate config.mak by > hand. If there are specific options always needed on a given arch, the > build process (even without configure being used) should automatically > add them to the specfile. Two ideas come to mind: 1) similar to alltypes.h(.sh), have an arch-specific script generate the specs file, or at least that portion of the specs file that might contain arch-specific variants. 2) add arch-specific variables in the relevant places and set them from outside, possibly by executing musl-gcc.specs.sh from within an arch-specific shell script. For instance: *cpp_options: $ARCH_SPECIFIC_CFLAGS -nostdinc -isystem $incdir %(old_cpp_options) > > Any good proposals? > > Rich