[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502143125.GO14673@brightrain.aerifal.cx>
Date: Wed, 2 May 2012 10:31:25 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: configure script for musl (?!)
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
