On 2019-05-17, Rich Felker wrote:
>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.

Sorry, didn't notice that.

New patch attached.


With 2 local llvm/clang patches, I am able to build musl powerpc64le with the following command:

../configure --target=powerpc64le AR=~/llvm/Release/bin/llvm-ar RANLIB=true CC=~/llvm/Release/bin/clang CFLAGS='-target powerpc64le-linux -mlong-double-64' LDFLAGS=-fuse-ld=lld --enable-debug

# "-linux" in "powerpc64le-linux" is important.
# If -target powerpc64le is used instead, clang will invoke gcc instead of itself in the linker stage, which will not work.