mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] configure: check whether linker works too
Date: Mon, 24 Oct 2016 19:23:08 -0400	[thread overview]
Message-ID: <20161024232308.GE19318@brightrain.aerifal.cx> (raw)
In-Reply-To: <004a5919-eb25-d4bf-a680-57049fa4d428@gmail.com>

On Mon, Oct 24, 2016 at 06:05:02PM -0500, Laine Gholson wrote:
> As a result of http://www.openwall.com/lists/musl/2016/10/22/3
> it has been shown that musl's current compiler sanity checks
> are inadequate. This patch checks if the compiler as a whole
> works properly, and moves the CPPFLAGS/CFLAGS/LDFLAGS sanity
> checks after the 'compiler works' check.
> 
> Patch and patch signature attached
> 
> Thanks,
>  Laine Gholson

> >From 99fd54d6f2b7c84a02c1ca0d5f1397d709c14313 Mon Sep 17 00:00:00 2001
> From: Laine Gholson <laine.gholson@gmail.com>
> Date: Mon, 24 Oct 2016 17:49:58 -0500
> Subject: [PATCH] configure: check whether linker works too
> 
> and move flag sanity checks to a seperate test
> ---
>  configure | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 707eb12..e7d565c 100755
> --- a/configure
> +++ b/configure
> @@ -236,8 +236,17 @@ printf "%s\n" "$CC"
>  test -n "$CC" || { echo "$0: cannot find a C compiler" ; exit 1 ; }
>  
>  printf "checking whether C compiler works... "
> -echo "typedef int x;" > "$tmpc"
> -if output=$($CC $CPPFLAGS $CFLAGS -c -o /dev/null "$tmpc" 2>&1) ; then
> +echo 'int main(void) { return 0; }' > "$tmpc"
> +if output=$($CC -o /dev/null "$tmpc" 2>&1) ; then
> +printf "yes\n"
> +else
> +printf "no; compiler output follows:\n%s\n" "$output"
> +exit 1
> +fi

As-is, this is not an acceptable change. When bootstrapping a new
toolchain, linking executables does not work because there is no libc
to link to. That's why we only test compiling and not linking.

The only need for a linker in the build process is building a shared
libc.so, and there are some linking tests that use -shared (which can
work without a libc.so, as long as -nostdlib is also being used). It
would be acceptable to add a linking test on which support for shared
library output depends; it should probably cause configure to fail if
--enable-shared was used (shared=yes) and otherwise should cause
shared=auto to become shared=no.

> +printf 'checking whether *FLAGS are sane... '
> +echo 'int main(void) { return 0; }' > "$tmpc"
> +if output=$($CC $CFLAGS $CPPFLAGS $LDFLAGS -o /dev/null "$tmpc" 2>&1) ; then
>  printf "yes\n"
>  else
>  printf "no; compiler output follows:\n%s\n" "$output"

I don't think this test is needed; you'll get a failure at make time
if you included bad flags. If there is a reason to prefer doing such a
test, there need to be separate ones for compiling and linking (since
linking might not work, e.g. if you have a compiler that can't produce
shared libraries).

Rich


  reply	other threads:[~2016-10-24 23:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 23:05 Laine Gholson
2016-10-24 23:23 ` Rich Felker [this message]
2016-10-25  0:00   ` Laine Gholson
2016-10-25  9:13     ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161024232308.GE19318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).