similar to: Building an LLVM cross-compiler

On Fri, 6 Nov 2020, Cág via llvm-dev wrote: > The process, in my opinion, should go like this: > 1. Get the sources (llvm, lld, compiler-rt, libunwind, libcxx...). > 2. Build an LLVM cross-compiler toolchain using native distribution's > compiler (i.e. build an x86_64 clang executable that targets aarch64). > 3. Cross-compile libc and other libraries/dependencies to run the

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Cág via > llvm-dev > Sent: Tuesday, November 10, 2020 8:49 AM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Building an LLVM cross-compiler > > Hi everyone, > > Just a quick update. Here's what worked for me here*: > 1. Get the sources. > 2.

Today, there're two different locations for runtimes files within Clang's installation: compiler-rt: headers: $prefix/lib/clang/$version/include(/sanitizer) libraries: $prefix/lib/clang/$version/lib/$os/libclang_rt.$name-$arch.$ext libc++, libc++abi, libunwind: headers: $prefix/include/c++/v1 libraries: $prefix/lib/$name.$ext The scheme used by libc++, libc++abi, libunwind

Thanks Shoaib for a great summary. To summarize this as an answer to Louis' questions: 1. What is a "Standalone build"? What does it enable that a normal monorepo build can't? This means building any of the runtimes separately, where the runtime's CMakeLists.txt (e.g. path/to/my/llvm-project/libcxx/CMakeLists.txt) is the top-level one. The reason for using this variant is

Hi everyone, I recently sent a message that may or may not have made it to the list, on problems building an LLVM cross-compiler. Now the issue seems clear to me and is irrelevant at this point, I would like to discuss the general issue. Suppose you have a host system, a Linux distribution on an x86_64 machine, and want to build a cross-compiler for aarch64 (or any platform supported by LLVM,

Hi everyone, Just a quick update. Here's what worked for me here*: 1. Get the sources. 2. Build clang, llvm, lld. 3. Install libc headers to a sysroot. 4. Build compiler-rt builtins and crt with the freshly-built clang. One need to set C_COMPILER_WORKS to skip the checks. 5. Build libc.a/libc.so Now the freshly-built clang can compile a "Hello, World" program. @Martin Storsjö

On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: > > Today, there're two different locations for runtimes files within > > Clang's installation: > > > > compiler-rt: > > headers: $prefix/lib/clang/$version/include(/sanitizer) > > libraries: >

You could try using zig for this. Here's an example build script of zig cross compiling llvm, lld, clang, and finally itself: https://github.com/ziglang/zig-bootstrap You can see the build script is not too complicated. The main trick is using CC and CXX to use `zig cc` and `zig c++` as drop-in replacements for a C and C++ compiler, respectively. I wrote some more details about this

[Cross-post to llvm-dev to make sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of

On Tue, Dec 19, 2017 at 12:33 PM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 12:53 PM, Petr Hosek wrote: > > On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs < > jonathan at codesourcery.com> wrote: > >> On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: >> > Today, there're two different locations for runtimes files within

Hello! On 11/10/20 2:49 PM, Cág via llvm-dev wrote: > Just a quick update. Here's what worked for me here*: > 1. Get the sources. > 2. Build clang, llvm, lld. > 3. Install libc headers to a sysroot. Alternatively, use a Debian-based system which allows co-installation of system libraries for multiple architectures (Multi-Arch). Never understood why other distributions

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

> On Nov 2, 2015, at 11:41 AM, Vasileios Kalintiris <Vasileios.Kalintiris at imgtec.com> wrote: > >> The problem comes when bootstrapping a cross-compiler toolchain. In order to >> have a cross-compiling toolchain that can build a “hello world” application you >> need four basic components: >> >> (1) clang >> (2) ld >> (3) libclang_rt

> > I will not be stripping out any of the existing CMake. If we go down this > path what I’m going to do is refactor the CMake to produce to logically > separated projects so that the builtins can be built with or without the > runtime libraries. It will all still be CMake-based. Sorry. s/stripping/seperating/g I was still thinking about the stripping of the IOS build from the OSX

On 12 June 2016 at 00:35, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I think the fundamental distinction needs to be following dependency >> graphs because if we don’t get rid of the circular dependency in >> bootstrapping there is no reason to make any changes. > > +1 for what Chandler said here. > > I don't think CMake itself per se

I am attempting to port an operating system project to use Clang/LLVM instead of GCC, but I'm having issues with Compiler-RT. Right now, the OS is being cross-compiled on an x86_64 host targeting ARMv7a. I built the LLVM toolchain according to the instructions, though I limited the supported targets to arm, x86, and x86_64 to reduce compilation time. I'm finding that compilation proceeds

I probably should have stated this in my last email. I see all three of these initiatives as separate restructuring changes. None of them should need to be tied to each other or block the others. > On Jun 10, 2016, at 11:23 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Fri, Jun 10, 2016 at 10:52 AM Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org

> On Nov 2, 2015, at 12:01 PM, Steve King <steve at metrokings.com> wrote: > > Hi Chris - Many thanks for airing all this. I'm now hopeful for an > end to my own hacks and false starts trying to fix these same > problems. My response is coming from the perspective of an > out-of-tree target without binutils or libgcc support. > > On Mon, Nov 2, 2015 at 9:10

Hi Peter, On Wed, 26 Feb 2020 at 18:37, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello Arslan, > > > I am guessing I can borrow libraries such as lc and lm from GCC > > arm-none-eabi*, but for clang_rt.builtins-arm.a (which I thought > > should've been built with LLVM build but I couldn't find that library > > in my build

Hi, I am trying to use LLVM/clang to build a binary for ARM Cortex M platforms. When I build my binary the linker fails to find these libraries. ./bin/clang++ -target arm-none-eabi -mcpu=cortex-m4 ./temp.cpp -L ./lib/ -L ./libexec/ -L ../build3_v7m/lib/ ld.lld: error: unable to find library -lunwind ld.lld: error: unable to find library -lc ld.lld: error: unable to find library -lm ld.lld: error: