Re: [PATCH] config.mak: add AR/RANLIB and delete ASMSUBARCH

[Rich Felker <dalias@libc.org>]

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@maskray.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