mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Cross compiling with LLVM/clang
@ 2021-11-10  6:28 Matt Andrews
  2021-11-10 15:40 ` Markus Wichmann
  2021-11-10 16:11 ` Rich Felker
  0 siblings, 2 replies; 5+ messages in thread
From: Matt Andrews @ 2021-11-10  6:28 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Cross compiling with LLVM/clang
  2021-11-10  6:28 [musl] Cross compiling with LLVM/clang Matt Andrews
@ 2021-11-10 15:40 ` Markus Wichmann
  2021-11-10 16:11 ` Rich Felker
  1 sibling, 0 replies; 5+ messages in thread
From: Markus Wichmann @ 2021-11-10 15:40 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Cross compiling with LLVM/clang
  2021-11-10  6:28 [musl] Cross compiling with LLVM/clang Matt Andrews
  2021-11-10 15:40 ` Markus Wichmann
@ 2021-11-10 16:11 ` Rich Felker
  2021-11-10 19:46   ` Matt Andrews
  1 sibling, 1 reply; 5+ messages in thread
From: Rich Felker @ 2021-11-10 16:11 UTC (permalink / raw)
  To: Matt Andrews; +Cc: musl

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Cross compiling with LLVM/clang
  2021-11-10 16:11 ` Rich Felker
@ 2021-11-10 19:46   ` Matt Andrews
  2021-11-10 22:43     ` Rich Felker
  0 siblings, 1 reply; 5+ messages in thread
From: Matt Andrews @ 2021-11-10 19:46 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Cross compiling with LLVM/clang
  2021-11-10 19:46   ` Matt Andrews
@ 2021-11-10 22:43     ` Rich Felker
  0 siblings, 0 replies; 5+ messages in thread
From: Rich Felker @ 2021-11-10 22:43 UTC (permalink / raw)
  To: Matt Andrews; +Cc: musl

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-11-10 22:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-10  6:28 [musl] Cross compiling with LLVM/clang Matt Andrews
2021-11-10 15:40 ` Markus Wichmann
2021-11-10 16:11 ` Rich Felker
2021-11-10 19:46   ` Matt Andrews
2021-11-10 22:43     ` Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).