Re: [musl] Cross compiling with LLVM/clang

[Rich Felker <dalias@libc.org>]

On Wed, Nov 10, 2021 at 05:28:57PM +1100, Matt Andrews wrote:
> Hi,
> 
> I've posted about this before, but I've been at this for a month now and
> I'm fresh out of ideas.
> 
> I could be making things hard for myself with my approach, but I want to
> understand what I'm doing wrong.
> 
> I'm trying to cross compile musl for armv7a-linux-eabihf and a cortex-a8
> cpu.
> 
> Here's what I'm doing
> 
> cd /usr/src/musl \
> && AR=/usr/lib/llvm-13/bin/llvm-ar \
> RANLIB=/usr/lib/llvm-13/bin/llvm-ranlib \
> CC=/usr/lib/llvm-13/bin/clang \
> CFLAGS="-fuse-ld=/usr/lib/llvm-13/bin/ld.lld --rtlib=compiler-rt
> -mcpu=cortex-a8" \
> LIBCC=-lcompiler_rt \
> ../configure \
> --prefix=$VECX/usr \
> --syslibdir=$VECX/lib \
> --target=armv7a-linux-eabihf \
> && make \
> && make install
> 
> Here's the output/error from ./configure
> 
> checking for C compiler... /usr/lib/llvm-13/bin/clang
> checking whether C compiler works... yes
> checking whether compiler accepts -Werror=unknown-warning-option... yes
> checking whether compiler accepts -Werror=unused-command-line-argument...
> yes
> checking whether compiler accepts -Werror=ignored-optimization-argument...
> yes
> checking whether linker accepts -Werror=unknown-warning-option... yes
> checking whether linker accepts -Werror=unused-command-line-argument... yes
> checking for C compiler family... clang
> checking for toolchain wrapper to build... clang
> checking target system type... armv7a-linux-eabihf
> checking whether compiler accepts -std=c99... yes
> checking whether compiler accepts -nostdinc... yes
> checking whether compiler accepts -ffreestanding... yes
> checking whether compiler accepts -fexcess-precision=standard... no
> checking whether compiler accepts -frounding-math... yes
> checking whether compiler needs attribute((may_alias)) suppression... no
> checking whether compiler accepts -Wa,--noexecstack... yes
> checking whether compiler accepts -fno-stack-protector... yes
> checking whether compiler accepts -fno-tree-loop-distribute-patterns... no
> checking whether we should preprocess assembly to add debugging
> information... no
> checking for optimization settings... using defaults
> checking whether compiler accepts -Os... yes
> components to be optimized for speed: internal malloc string
> checking whether compiler accepts -pipe... yes
> checking whether compiler accepts -fomit-frame-pointer... yes
> checking whether compiler accepts -fno-unwind-tables... yes
> checking whether compiler accepts -fno-asynchronous-unwind-tables... yes
> checking whether compiler accepts -ffunction-sections... yes
> checking whether compiler accepts -fdata-sections... yes
> checking whether compiler accepts -w... yes
> checking whether compiler accepts -Wno-pointer-to-int-cast... yes
> checking whether compiler accepts -Werror=implicit-function-declaration...
> yes
> checking whether compiler accepts -Werror=implicit-int... yes
> checking whether compiler accepts -Werror=pointer-sign... yes
> checking whether compiler accepts -Werror=pointer-arith... yes
> checking whether compiler accepts -Werror=int-conversion... yes
> checking whether compiler accepts -Werror=incompatible-pointer-types... yes
> checking whether compiler accepts -Werror=discarded-qualifiers... no
> checking whether compiler accepts -Werror=discarded-array-qualifiers... no
> checking whether compiler accepts -Qunused-arguments... yes
> checking whether compiler accepts -Waddress... yes
> checking whether compiler accepts -Warray-bounds... yes
> checking whether compiler accepts -Wchar-subscripts... yes
> checking whether compiler accepts -Wduplicate-decl-specifier... yes
> checking whether compiler accepts -Winit-self... yes
> checking whether compiler accepts -Wreturn-type... yes
> checking whether compiler accepts -Wsequence-point... yes
> checking whether compiler accepts -Wstrict-aliasing... yes
> checking whether compiler accepts -Wunused-function... yes
> checking whether compiler accepts -Wunused-label... yes
> checking whether compiler accepts -Wunused-variable... yes
> checking preprocessor condition __PIC__... false
> checking whether linker accepts -Wl,--sort-section,alignment... yes
> checking whether linker accepts -Wl,--sort-common... yes
> checking whether linker accepts -Wl,--gc-sections... yes
> checking whether linker accepts -Wl,--hash-style=both... yes
> checking whether linker accepts -Wl,--no-undefined... yes
> checking whether linker accepts -Wl,--exclude-libs=ALL... yes
> checking whether linker accepts -Wl,--dynamic-list=./dynamic.list... yes
> using compiler runtime libraries: -lcompiler_rt
> checking preprocessor condition __thumb2__... false
> checking preprocessor condition __ARMEB__... false
> checking preprocessor condition __ARM_PCS_VFP... false
> checking whether clang's vfp asm constraints work... yes
> checking whether compiler's long double definition matches float.h... no
> ../configure: error: unsupported long double type
> ------
> executor failed running [/bin/sh -c cd /usr/src/musl &&
> AR=/usr/lib/llvm-13/bin/llvm-ar RANLIB=/usr/lib/llvm-13/bin/llvm-ranlib
> CC=/usr/lib/llvm-13/bin/clang CFLAGS="-fuse-ld=/usr/lib/llvm-13/bin/ld.lld
> --rtlib=compiler-rt -mcpu=cortex-a8" LIBCC=-lcompiler_rt ./configure
> --prefix=$VECX/usr --syslibdir=$VECX/lib --target=armv7a-linux-eabihf &&
> make && make install]: exit code: 1
> 
> I had a look at the configure script to see what causes that error and I
> think it's building a test program?
> 
> Is the long double type something that is in compiler-rt? Does compiler-rt
> also have to be built for armv7a-linux-eabihf as well?

As far as I can tell you're not invoking configure to cross compile.
You told it the target (note: this should really be called host but it
doesn't matter) is arm but you're invoking the compiler as "clang" so
it will just be whatever clang's default target is (probably x86_64).

If you want to cross compile, you need something like
CC="/usr/lib/llvm-13/bin/clang --target=armv7-a" and you also need to
have a suitable compiler-rt for arm available.

We should probably do something to detect this kind of breakage
earlier than at long double type mismatch.

Rich