[-- Attachment #1: Type: text/plain, Size: 5321 bytes --] 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? [-- Attachment #2: Type: text/html, Size: 22008 bytes --]
On Wed, Nov 10, 2021 at 05:28:57PM +1100, Matt Andrews wrote:
> ./configure: error: unsupported long double type
musl supports three implementations of "long double": IEEE 754 double
precision, IEEE 754 double extended precision, and IEEE 754 quad
precision (also known as Binary-64, Binary-80, and Binary-128,
respectively). The configure program attempts to figure out which of
these your compiler is using by including <float.h> and testing the
standard macros LDBL_MANT_DIG and LDBL_MAX_EXP for well known
combinations.
Thankfully, with gcc and clang these are easy to find out:
$COMPILER -E -dM -xc /dev/null | grep LDBL
Can you post the output of this (setting COMPILER to "clang
--target=whatever")? It is possible you need another switch to change
the "long double" implementation. Note that that needs to be consistent
across all compiles against musl.
Ciao,
Markus
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
[-- Attachment #1: Type: text/plain, Size: 884 bytes --] On Thu, Nov 11, 2021 at 3:11 AM Rich Felker <dalias@libc.org> wrote: > 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 > Thanks Rich, this worked. I actually put "--target=armv7a-linux-eabihf" into CFLAGS. I had done that at some earlier stage, but it caused another problem so I removed it. Now for the job of cross compiling compiler-rt... [-- Attachment #2: Type: text/html, Size: 1328 bytes --]
On Thu, Nov 11, 2021 at 06:46:30AM +1100, Matt Andrews wrote:
> On Thu, Nov 11, 2021 at 3:11 AM Rich Felker <dalias@libc.org> wrote:
>
> > 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
> >
>
> Thanks Rich, this worked. I actually put "--target=armv7a-linux-eabihf"
> into CFLAGS. I had done that at some earlier stage, but it caused another
> problem so I removed it.
It should be in CC, not CFLAGS, as it's actually the *identity of the
compiler* you're setting, not mere options. It probably works in
practice in either, but to be safe, use CC.
Rich