[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190517164342.GB23599@brightrain.aerifal.cx>
Date: Fri, 17 May 2019 12:43:42 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] config.mak: add AR/RANLIB and delete ASMSUBARCH
On Fri, May 17, 2019 at 11:35:37PM +0800, Fangrui Song wrote:
> By default, if I specify --target=aarch64, AR=aarch64-ar is used, which is apparently not available.
>
> With this patch, I am able to build an aarch64 musl with:
>
> ../configure --target=aarch64 AR=llvm-ar RANLIB=true CC=clang CFLAGS=--target=aarch64-linux-musl LDFLAGS="-fuse-ld=lld -L/path/to/aarch64/libgcc.a/and/libgcc_eh.a" --enable-debug
>
> ASMSUBARCH is no longer in use as of commit 0f814a4e57e80d2512934820b878211e9d71c93e.
>
> You may also delete the following line
>
> test -z "$LIBCC" && tryldflag LIBCC -lcompiler_rt
>
> because compiler-rt (part of which is nearly a replacement of libgcc) is something like:
>
> /home/ray/llvm/Release/lib/clang/9.0.0/lib/linux/libclang_rt.builtins-x86_64.a
>
> not libcompiler_rt.a
>
> % clang -print-resource-dir
> /home/ray/llvm/Release/lib/clang/9.0.0
> % clang -rtlib=compiler-rt -print-libgcc-file-name
> /home/ray/llvm/Release/lib/clang/9.0.0/lib/linux/libclang_rt.builtins-x86_64.a
I think this was discussed before and there were suggestions for
improving the behavior overall. That might include removing
-lcompiler_rt search, but there may be cases where it makes sense
(maybe using gcc with libgcc intentionally replaced?)
> BTW, I am not sure if libgcc_eh.a is needed.
At one point, some archs' libgcc had a gratuitous dependency on
libgcc_eh due to soft division functions pulling in exception crap for
divide-by-zero. This is obviously wrong, but I felt it was outside the
scope of musl to try to fix it. Since libgcc_eh is an archive library,
including it in the link is a nop as long as nothing pulls in a
dependency on it, so it shouldn't hurt with non-broken libgcc.
> From 1a9f27d0a311210829a021384eb36332bc7456d0 Mon Sep 17 00:00:00 2001
> From: Fangrui Song <i@...kray.me>
> Date: Fri, 17 May 2019 08:15:52 -0700
> Subject: [PATCH] config.mak: add AR/RANLIB and delete ASMSUBARCH
These are independent, unrelated changes and shouldn't be in a commit
together.
> ---
> configure | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/configure b/configure
> index 2123ddce..2c866955 100755
> --- a/configure
> +++ b/configure
> @@ -172,6 +172,8 @@ case "$arg" in
> --host=*|--target=*) target=${arg#*=} ;;
> --build=*) build=${arg#*=} ;;
> -* ) echo "$0: unknown option $arg" ;;
> +AR=*) AR=${arg#*=} ;;
> +RANLIB=*) RANLIB=${arg#*=} ;;
> CC=*) CC=${arg#*=} ;;
> CFLAGS=*) CFLAGS=${arg#*=} ;;
> CPPFLAGS=*) CPPFLAGS=${arg#*=} ;;
> @@ -680,11 +682,6 @@ fi
> test "$SUBARCH" \
> && printf "configured for %s variant: %s\n" "$ARCH" "$ARCH$SUBARCH"
>
> -case "$ARCH$SUBARCH" in
> -arm) ASMSUBARCH=el ;;
> -*) ASMSUBARCH=$SUBARCH ;;
> -esac
> -
> #
> # Some archs (powerpc) have different possible long double formats
> # that the compiler can be configured for. The logic for whether this
> @@ -728,9 +725,10 @@ cat << EOF
> # This version of config.mak was generated by:
> # $cmdline
> # Any changes made here will be lost if configure is re-run
> +AR = $AR
> +RANLIB = $RANLIB
This completely breaks the behavior with AR and RANLIB not specified
explicitly, including a plain default ./configure command. They'll now
be blank rather than $(CROSS_COMPILE)-{ar,ranlib} evaluated at
make-time.
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.
