similar to: [RFC] Strategies for Bootstrapping Compiler-RT builtins

> 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

You’ve hit on one of the odd historical messes in LLVM. Compiler-RT can’t really be treated as a monolithic set of libraries when you are bootstrapping. In order to even configure the LLVM sanitizer runtimes you need libc and many other OS interfaces, so when bootstrapping you need to build the compiler-rt builtins library separately from the sanitizers. This can be done either by using the

> On Dec 18, 2016, at 3:48 AM, Dmitry Golovin <dima at golovin.in> wrote: > > > > 16.12.2016, 18:23, "Vedant Kumar" <vsk at apple.com>: >>> On Dec 16, 2016, at 7:06 AM, Dmitry Golovin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and

> On Nov 2, 2015, at 10:10 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> Today building this toolchain with CMake is impossible because you cannot configure the cross-compiled builtins. The failure is a result of CMake’s try_compile function always testing a full compile then link operation. When bootstrapping a cross-compiler this will always fail because

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

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

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

On Thu, Aug 03, 2017 at 08:22:24AM -0600, Jonathan Roelofs wrote: > IIUC, you don't want to cross compile llvm itself (which is what those > instructions are for), but instead you want to *use* llvm to cross compile > things. > > To build your sysroot, you'll need to cross-build: > > 1) A libc. Good choices for that for baremetal are: newlib or musl. > 2)

16.12.2016, 18:23, "Vedant Kumar" <vsk at apple.com>: >>  On Dec 16, 2016, at 7:06 AM, Dmitry Golovin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>  I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and lld (under `tools` directory) and libunwind, compiler-rt, libcxx and libcxxabi (under `projects` directory). All are

> On Nov 2, 2015, at 2:44 PM, Steve King <steve at metrokings.com> wrote: > > On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: >> Sadly, I believe there are licensing reasons why the builtins can’t be in the LLVM repo. > > Repos and licenses are orthogonal, but I get the concern. > > Switching gears to other questions: > Should

Moving to llvm-dev (I think this has gone a bit further than a patch review discussion) In hindsight I probably should have explained more of my thinking on this with the patch, or done an RFC on llvm-dev to start with. I’l do that now, and answer the questions along the way. I sent a separate email discussing Justin’s patch review feedback. In the build system today there is no strong

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 may also take a look at the ELLCC project (www.ellcc.org <http://www.ellcc.org/>). As far as I understand it they produce and package cross toolchains for a number of popular targets. - Matthias > On Aug 4, 2017, at 12:54 PM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 8/4/17 1:14 PM, Goran Mekić via llvm-dev wrote: >> On

On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: [ brutal-snip ] ... > [ TODO#S: Before doing a 2nd build (and in a 3rd run using more > optimized binaries) ] > > How do I anable LTO via CMAKE? > > > LLVM_ENALBLE_LTO=On > [ v4 of my build-script attached ] Hi Chris, thanks for the response! That seems to work (see below). $ cd

This is currently a rough area in our build system, but there are two CMake options you probably need to set. (1) -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On —> This option causes the build to use the just-built clang when building compiler-rt (2) -DCOMPILER_RT_DEFAULT_TARGET_ARCH=??? —> This is where you specify which architecture you want to build the compiler-rt archives and libraries for

Folks, I'm running the libc++ tests in tree [1] and I'm seeing two class of errors: 1. -lrt is used, but there is no such "librt.a" in the path. Results are that some symbols are not found, or that the DSO object wasn't. Adding a symlink in build/lib/librt.a to build/clang/3.8.0/lib/linux/libclang_rt.builtins-aarch64.a worked. 2. "collate_byname failed to construct

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

Hello Christian, I reran my script with a similar cmake command to yours. After the build finished the following command from the build directory gave me: find . -name \*builtins.a ./lib/clang/9.0.0/armv6m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7em-none-eabi/lib/libclang_rt.builtins.a I hope you see something like

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

It seems to me that the feedback here has been generally positive, but a lot of different ideas have been added to the mix. To focus conversation and move things along I'm going to provide a summary of changes with proposals for rollout. Splitting Compiler-RT If we want to split compiler-rt, which I think makes a lot of sense, I think the best path forward is to copy the trunk (via svn cp).