mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Laine Gholson <laine.gholson@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH] configure: check whether linker works too
Date: Mon, 24 Oct 2016 19:00:55 -0500	[thread overview]
Message-ID: <ce702cb3-a9d9-50c5-c3d1-9e8892e2d091@gmail.com> (raw)
In-Reply-To: <20161024232308.GE19318@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]

On 10/24/16 18:23, Rich Felker wrote:
> 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.
Fixed patch attached: add -nostdlib and -shared, and only check if
linker works if $shared = yes
>
>> +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).
I insist on it, some users may use insane CFLAGS values that don't even
work, and it tells them that their CFLAGS are wrong.
>
> Rich
>
Laine Gholson

[-- Attachment #2: configure.patch --]
[-- Type: text/x-patch, Size: 1533 bytes --]

diff --git a/configure b/configure
index 707eb12..c363079 100755
--- a/configure
+++ b/configure
@@ -237,13 +237,49 @@ 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
+if output=$($CC -c -o /dev/null "$tmpc" 2>&1) ; then
 printf "yes\n"
 else
 printf "no; compiler output follows:\n%s\n" "$output"
 exit 1
 fi
 
+if test x"$shared" != xno ; then
+  printf "checking whether linker works... "
+  echo "int main(void) { return 0; }" > "$tmpc"
+  if output=$($CC -nostdlib -shared -o /dev/null "$tmpc" 2>&1) ; then
+  printf "yes\n"
+  else
+  if test x"$shared" = xyes ; then
+  printf "no; compiler output follows:\n%s\n" "$output"
+  exit 1
+  else
+  printf "no; shared library disabled\n"
+  shared=no
+  fi
+  fi
+fi
+
+printf "checking whether CFLAGS and CPPFLAGS are sane... "
+echo "typedef int x;" > "$tmpc"
+if output=$($CC $CFLAGS $CPPFLAGS -c -o /dev/null "$tmpc" 2>&1) ; then
+printf "yes\n"
+else
+printf "no; compiler output follows:\n%s\n" "$output"
+exit 1
+fi
+
+if test x"$shared" != xno ; then
+  printf "checking whether LDFLAGS are sane... "
+  echo "int main(void) { return 0; }" > "$tmpc"
+  if output=$($CC $LDFLAGS -nostdlib -shared -o /dev/null "$tmpc" 2>&1) ; then
+  printf "yes\n"
+  else
+  printf "no; compiler output follows:\n%s\n" "$output"
+  exit 1
+  fi
+fi
+
 #
 # Figure out options to force errors on unknown flags.
 #

  reply	other threads:[~2016-10-25  0:00 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
2016-10-25  0:00   ` Laine Gholson [this message]
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=ce702cb3-a9d9-50c5-c3d1-9e8892e2d091@gmail.com \
    --to=laine.gholson@gmail.com \
    --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).