mailing list of musl libc
 help / color / mirror / code / Atom feed
* [PATCH] fix wrapper auto detection in configure
@ 2016-01-22 21:56 Szabolcs Nagy
  2016-01-22 23:47 ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Szabolcs Nagy @ 2016-01-22 21:56 UTC (permalink / raw)
  To: musl

the libc header based test is wrong if there are no such headers on the
system only a free standing cc, which should be enough for a musl build.

check for *-musl* in the target triplet instead.
---
 configure | 60 ++++++++++++++++++++++++++++--------------------------------
 1 file changed, 28 insertions(+), 32 deletions(-)

diff --git a/configure b/configure
index 5b97f71..a629290 100755
--- a/configure
+++ b/configure
@@ -255,15 +255,38 @@ fi
 echo "$cc_family"
 
 #
+# Find the target architecture
+#
+printf "checking target system type... "
+test -n "$target" || target=$($CC -dumpmachine 2>/dev/null) || target=unknown
+printf "%s\n" "$target"
+
+#
+# Convert to just ARCH
+#
+case "$target" in
+# Catch these early to simplify matching for 32-bit archs
+mips64*|powerpc64*) fail "$0: unsupported target \"$target\"" ;;
+arm*) ARCH=arm ;;
+aarch64*) ARCH=aarch64 ;;
+i?86*) ARCH=i386 ;;
+x86_64-x32*|x32*|x86_64*x32) ARCH=x32 ;;
+x86_64*) ARCH=x86_64 ;;
+mips*) ARCH=mips ;;
+microblaze*) ARCH=microblaze ;;
+or1k*) ARCH=or1k ;;
+powerpc*) ARCH=powerpc ;;
+sh[1-9bel-]*|sh|superh*) ARCH=sh ;;
+unknown) fail "$0: unable to detect target arch; try $0 --target=..." ;;
+*) fail "$0: unknown or unsupported target \"$target\"" ;;
+esac
+
+#
 # Figure out toolchain wrapper to build
 #
 if test "$wrapper" = auto -o "$wrapper" = detect ; then
-echo "#include <stdlib.h>" > "$tmpc"
-echo "#if ! __GLIBC__" >> "$tmpc"
-echo "#error no" >> "$tmpc"
-echo "#endif" >> "$tmpc"
 printf "checking for toolchain wrapper to build... "
-if test "$wrapper" = auto && ! $CC -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
+if test "$wrapper" = auto && fnmatch '*-musl*' "$target" ; then
 echo "none"
 elif test "$cc_family" = gcc ; then
 gcc_wrapper=yes
@@ -288,33 +311,6 @@ tools="$tools obj/musl-clang obj/ld.musl-clang"
 fi
 
 #
-# Find the target architecture
-#
-printf "checking target system type... "
-test -n "$target" || target=$($CC -dumpmachine 2>/dev/null) || target=unknown
-printf "%s\n" "$target"
-
-#
-# Convert to just ARCH
-#
-case "$target" in
-# Catch these early to simplify matching for 32-bit archs
-mips64*|powerpc64*) fail "$0: unsupported target \"$target\"" ;;
-arm*) ARCH=arm ;;
-aarch64*) ARCH=aarch64 ;;
-i?86*) ARCH=i386 ;;
-x86_64-x32*|x32*|x86_64*x32) ARCH=x32 ;;
-x86_64*) ARCH=x86_64 ;;
-mips*) ARCH=mips ;;
-microblaze*) ARCH=microblaze ;;
-or1k*) ARCH=or1k ;;
-powerpc*) ARCH=powerpc ;;
-sh[1-9bel-]*|sh|superh*) ARCH=sh ;;
-unknown) fail "$0: unable to detect target arch; try $0 --target=..." ;;
-*) fail "$0: unknown or unsupported target \"$target\"" ;;
-esac
-
-#
 # Try to get a conforming C99 freestanding environment
 #
 tryflag CFLAGS_C99FSE -std=c99
-- 
2.7.0




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] fix wrapper auto detection in configure
  2016-01-22 21:56 [PATCH] fix wrapper auto detection in configure Szabolcs Nagy
@ 2016-01-22 23:47 ` Rich Felker
  2016-01-23  0:32   ` Szabolcs Nagy
  0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2016-01-22 23:47 UTC (permalink / raw)
  To: musl

On Fri, Jan 22, 2016 at 10:56:03PM +0100, Szabolcs Nagy wrote:
> the libc header based test is wrong if there are no such headers on the
> system only a free standing cc, which should be enough for a musl build.

I'm trying to understand the usage case you're concerned about. Is it
failing to build the wrapper for a glibc-targeted toolchain that
doesn't actually have glibc installed? Is there a reason you woul want
the wrapper in this case?

> check for *-musl* in the target triplet instead.

I don't think we depend on the target tuple at all now except as a way
of identifying the arch. It's only available with gcc, not other
compilers that lack -dumpmachine. I was actually thinking about this
issue a couple days ago and wonder if we should instead check for
predefined macros defined in the psABI for each arch to determine the
arch. This would also work on non-gcc compilers so you don't have to
manually pass the target arch (or tuple) to configure for them.

Anyway if I can understand what real problem you're trying to solve
maybe I can come up with a better approach that doesn't expend
dependency on having a named target tuple.

Rich


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] fix wrapper auto detection in configure
  2016-01-22 23:47 ` Rich Felker
@ 2016-01-23  0:32   ` Szabolcs Nagy
  0 siblings, 0 replies; 3+ messages in thread
From: Szabolcs Nagy @ 2016-01-23  0:32 UTC (permalink / raw)
  To: musl

* Rich Felker <dalias@libc.org> [2016-01-22 18:47:45 -0500]:
> On Fri, Jan 22, 2016 at 10:56:03PM +0100, Szabolcs Nagy wrote:
> > the libc header based test is wrong if there are no such headers on the
> > system only a free standing cc, which should be enough for a musl build.
> 
> I'm trying to understand the usage case you're concerned about. Is it
> failing to build the wrapper for a glibc-targeted toolchain that
> doesn't actually have glibc installed? Is there a reason you woul want
> the wrapper in this case?
> 

distros package libc-headers separately and
apparently one can install gcc without it
and that should be enough to build musl.

> > check for *-musl* in the target triplet instead.
> 
> I don't think we depend on the target tuple at all now except as a way
> of identifying the arch. It's only available with gcc, not other
> compilers that lack -dumpmachine. I was actually thinking about this
> issue a couple days ago and wonder if we should instead check for
> predefined macros defined in the psABI for each arch to determine the
> arch. This would also work on non-gcc compilers so you don't have to
> manually pass the target arch (or tuple) to configure for them.
> 

makes sense
but note that only gcc and clang matter here
(the wrapper will be disabled for other compilers)

> Anyway if I can understand what real problem you're trying to solve
> maybe I can come up with a better approach that doesn't expend
> dependency on having a named target tuple.
> 
> Rich


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-01-23  0:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-22 21:56 [PATCH] fix wrapper auto detection in configure Szabolcs Nagy
2016-01-22 23:47 ` Rich Felker
2016-01-23  0:32   ` Szabolcs Nagy

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).