From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/792 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: configure script for musl (?!) Date: Wed, 2 May 2012 10:31:25 -0400 Message-ID: <20120502143125.GO14673@brightrain.aerifal.cx> References: <20120501225408.GM14673@brightrain.aerifal.cx> <20120501233926.GN14673@brightrain.aerifal.cx> <20120502140004.GB17745@openwall.com> 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: dough.gmane.org 1335968893 31189 80.91.229.3 (2 May 2012 14:28:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 May 2012 14:28:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-793-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 02 16:28:10 2012 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 1SPaXJ-0004LY-Tu for gllmg-musl@plane.gmane.org; Wed, 02 May 2012 16:28:10 +0200 Original-Received: (qmail 22172 invoked by uid 550); 2 May 2012 14:28:08 -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 22147 invoked from network); 2 May 2012 14:28:02 -0000 Content-Disposition: inline In-Reply-To: <20120502140004.GB17745@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:792 Archived-At: On Wed, May 02, 2012 at 06:00:04PM +0400, Solar Designer wrote: > Rich, > > This approach (including not using autoconf specifically) makes sense to > me. One general problem with it, though, is that errors are not > distinguished from actually and purposefully missing features. > Sometimes it is preferable for the build to fail when an expected system > feature is not present rather than for it to succeed with unexpectedly > altered functionality. This is especially true if the non-detected > feature had security relevance. On Owl, we have the configure-presets > script for this reason - to pre-populate autoconf configure's cache. I don't think we have any situations like that. The only options that are "essential" but might fail are GCC-specific options to turn the compiler into a conforming C99 freestanding implementation. The only reason I test them at all is to support hypothetical non-GCC-compatible compilers, and I assume (1) they're already sufficiently conforming, and (2) if the user is using a non-mainstream compiler, they know best what they're doing. As for the floating point ones, only gcc >= 4.5.x can really give correct behavior on x86, but -ffloat-store is sufficient to be mostly correct, and the difference is usually just very small rounding errors. For the really important functions that need to be correctly rounded, glibc doesn't even get them right anyway, and we have asm that DOES get them right even if the compiler is broken when it comes to compiling the portable (in theory; if compilers weren't broken) C version. > On Tue, May 01, 2012 at 07:39:26PM -0400, Rich Felker wrote: > > # Get a temp filename we can use > > test -n "$TMPDIR" && tmpc="$TMPDIR/conf$$.c" || tmpc="/tmp/conf$$.c" > > set -C > > > "$tmpc" || { > > echo "$0: cannot create temporary file $tmpc" > > exit 1 > > } > > set +C > > trap 'rm "$tmpc"' EXIT > > Is "set -C" sufficiently portable? (I don't know. I guess that it is > if you're using it here.) It's POSIX. My policy for this and future configure scripts I write is that you need a POSIX compatible shell to run configure. This is the same as MPlayer and FFmpeg/libav policy and I remember they took some heat for it back in the day from users of broken unices like Solaris, but telling those users to add /usr/xpg4/bin to their path and invoke configure with that version of the shell generally made them happy. I suspect it's a non-issue in 2012, and especially for musl where building on anything non-Linux-based (and thus anything without [bd]?ash as the shell) is going to be a special cross-compiling case. > Assuming that "set -C" works, another user is able to prevent the above > from working by pre-creating the file. I understand that you can't just > use mktemp here, and implementing its full functionality right in your > shell script is not pretty. Yes, mktemp does not work because it does not let you specify a suffix, and most compilers fail to recognize input files as C unless they have a .c suffix. It has a dry run option just to generate the filename (and let the caller handle creating it like we do now) but unfortunately busybox mktemp does not know that option so it doesn't seem at all safe/portable. I've actually been working on the issue and updated it to use $$, $PPID, and a retry counter, so random failures will be extremely rare. If anyone thinks it still matters, I'll add $(date|cksum) too. > Another issue is that if the script is running with a relaxed umask like > 002, then another user (in the same group, if relevant) may not only > notice that musl is being compiled, but also inject their own C code > into the temporary file and maybe take over the musl-building user > account (depending on whether you run the compiled code or not, as well > as on the compiler's features and bugs available to be invoked from the > source). Perhaps you need to set a safe umask like 077 in this script > before it creates the temporary file (or chmod the file right after it's > been created, before its first actual use - and exit if the chmod fails). Indeed, this seems like a good idea. > Rather than use $TMPDIR or /tmp, I think it'd be safer to place the file > in the same directory with the configure script or in the current > directory. You're going to create config.mak in one of these > directories anyway - so just create the temporary file in that same > directory not to incur any extra risk (that you do by writing into a > second directory). This seems reasonable. Rich