From: Nagakamira <nagakamira@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [musl] Newbie cross compiling with LLVM
Date: Tue, 12 Oct 2021 22:35:30 -0700 [thread overview]
Message-ID: <CAEqUM+cmbC458mYpNqEtCPSpDps8uSW7HQ3yNTjrek731HBdyQ@mail.gmail.com> (raw)
In-Reply-To: <CAD0C5PADUUykKQyoB3OvS=O74c2LN_cq7yLLNH6N8G8Tmm4cuA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7320 bytes --]
you need to compile compiler-rt builtins and put them in clang folder and
then pass LIBCC="$(clang --target=blah-blah-blah -print-libgcc-file-name)"
On Tue, Oct 12, 2021 at 7:34 PM Matt Andrews <mattandrews@gmail.com> wrote:
> I'm currently using this to compile with LLVM
>
> 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
> --target=armv7a-linux-eabihf -mcpu=cortex-a8" \
> LIBCC=-lcompiler_rt \
> ./configure \
> --prefix=$PREFIX/usr \
> --syslibdir=$PREFIX/lib \
> --target=armv7a-linux-eabihf \
> && make \
> && make install
>
> This is the output 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... true
> checking whether clang's vfp asm constraints work... yes
> configured for arm variant: armhf
> checking whether compiler's long double definition matches float.h... yes
> checking preprocessor condition __FAST_MATH__... false
> creating config.mak... done
>
> but now I get this error when compiling
>
> ld.lld: error: unable to find library -lcompiler_rt
>
> Have I made an error in the way I'm calling ./configure?
>
> Just to reiterate, I'm trying to use LLVM to cross compile from x86_64
> Linux to armv7a-linux-eabihf.
>
> On Tue, Oct 12, 2021 at 5:09 PM Nagakamira <nagakamira@gmail.com> wrote:
>
>> You can pass --unwindlib=libunwind and rtlib, they are both link options
>>
>> On Tue, Oct 12, 2021, 8:55 AM Matt Andrews <mattandrews@gmail.com> wrote:
>>
>>> > --rtlib=compiler-rt
>>>
>>> Is that a compiler option or a linker option? I used it in both places,
>>> but still get the same error.
>>>
>>> On Tue, Oct 12, 2021 at 4:00 PM Nagakamira <nagakamira@gmail.com> wrote:
>>>
>>>> --rtlib=compiler-rt
>>>>
>>>> On Tue, Oct 12, 2021, 7:58 AM Matt Andrews <mattandrews@gmail.com>
>>>> wrote:
>>>>
>>>>> > -fuse-ld=lld
>>>>>
>>>>> I actually used
>>>>>
>>>>> -fuse-ld=ld.lld
>>>>>
>>>>> That did the trick, but has unlocked another error
>>>>>
>>>>> ld.lld: error: unable to find library -lgcc
>>>>> ld.lld: error: unable to find library -lgcc_eh
>>>>>
>>>>> I thought musl compiles with it's own headers?
>>>>>
>>>>> On Tue, Oct 12, 2021 at 3:54 PM Nagakamira <nagakamira@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> -fuse-ld=lld
>>>>>>
>>>>>> On Tue, Oct 12, 2021, 3:26 AM Jeffrey Walton <noloader@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Mon, Oct 11, 2021 at 7:55 PM Matt Andrews <mattandrews@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > >> How do I specify which linker to use?
>>>>>>> > >
>>>>>>> > >LD. Also see
>>>>>>> https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
>>>>>>> .
>>>>>>> >
>>>>>>> > Looking at the ./configure for musl (which is not based on
>>>>>>> autoconf according to the docs), there is no mention of LD. Setting LD for
>>>>>>> ./configure and/or the call to make still results in the error.
>>>>>>> >
>>>>>>> > Who calls the linker? The compiler or make? Shouldn't clang know
>>>>>>> where it's linker is? How to tell clang which linker to use?
>>>>>>>
>>>>>>> You can have the compiler driver call the linker for you by
>>>>>>> specifying
>>>>>>> -o with an output file name. In that case, $CC or $CXX will drive the
>>>>>>> link. And in this case, your LDFLAGS should prefix options with -Wl
>>>>>>> to
>>>>>>> tell the compiler driver the option is for the linker.
>>>>>>>
>>>>>>> Jeff
>>>>>>>
>>>>>>
[-- Attachment #2: Type: text/html, Size: 26240 bytes --]
prev parent reply other threads:[~2021-10-13 5:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 20:56 Matt Andrews
2021-10-10 22:43 ` Quentin Rameau
2021-10-10 23:21 ` Matt Andrews
2021-10-11 17:20 ` Khem Raj
2021-10-11 17:40 ` Jeffrey Walton
2021-10-11 23:55 ` Matt Andrews
2021-10-12 0:24 ` Jeffrey Walton
2021-10-12 4:53 ` Nagakamira
2021-10-12 4:57 ` Matt Andrews
2021-10-12 5:00 ` Nagakamira
2021-10-12 5:55 ` Matt Andrews
2021-10-12 6:09 ` Nagakamira
2021-10-13 2:34 ` Matt Andrews
2021-10-13 5:35 ` Nagakamira [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEqUM+cmbC458mYpNqEtCPSpDps8uSW7HQ3yNTjrek731HBdyQ@mail.gmail.com \
--to=nagakamira@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).