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