similar to: Building an LLVM cross-compiler

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

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

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

Who maintains apt.llvm.org? On 11/27/18 9:25 AM, Andrew Kelley wrote: > ---------- Forwarded message --------- > From: Andrew Kelley <superjoe30 at gmail.com> > Date: Mon, Nov 26, 2018 at 10:38 AM > Subject: apt.llvm.org has the wrong binaries/headers for llvm-toolchain-xenial-7 > To: LLVM Dev <llvm-dev at lists.llvm.org> > > > This build worked on Nov 24 and

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

Zig Programming Language Zig <http://ziglang.org/> is a system programming language which prioritizes optimality, safety, and readability. It integrates closely with C and is intended to eventually take the place of C. It uses LLVM to produce highly optimized native code and to cross-compile for any target out of the box. Zig is in alpha; progress toward a beta release is underway.

+Rui and Peter On Wed, Jul 25, 2018 at 8:34 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's a fix: > > --- a/lld/COFF/Driver.cpp > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > +

I've got a patched LLD 5.0.0 like this: diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp index 854c3e69..8bab1c11 100644 --- a/deps/lld/COFF/Driver.cpp +++ b/deps/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); -

It appears that there was an out-of-band patch from Samuel Thibault: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/7/debian/patches/D54378-hurd-triple.diff Although the patch was approved here https://reviews.llvm.org/D54378 Is this patch going to land in 7.0.1 or 8? kristopher > Here's further proof: > > wget >

I think you want to call freeArena() before returning from lld::coff::link. On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I believe this line is the culprit: > > COFF/Driver.cpp:102: > make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take ownership > > Patch forthcoming. > > > On Sun, Oct

I'm copying some LLD code into my codebase like this: // workaround for LLD not exposing ability to convert .def to .lib #include <set> namespace lld { namespace coff { class SymbolBody; class StringChunk; struct Symbol; struct Export { StringRef Name; // N in /export:N or /export:E=N StringRef ExtName; // E in /export:E=N SymbolBody *Sym = nullptr; uint16_t Ordinal

I'd be interested in the existence of a high-quality, open-source, portable linker for apple platforms, but not enough to help make that happen. If I _was_ gonna work on something related to that, I'd probably be inclined to instead add any required features to allow an ELF linker to target a notional darwin-elf target, and to have clang emit darwin-elf object files, and then write a

On Wed, Jun 14, 2017 at 7:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Jun 14, 2017 at 4:24 PM, Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm copying some LLD code into my codebase like this: >> >> // workaround for LLD not exposing ability to convert .def to .lib >> >> #include <set> >>

Thank you for this exciting update about LLD. I will start experimenting with using liblld in Zig (http://ziglang.org/) instead of starting a child process to invoke the system linker. Once liblld makes it into the various package managers out there, this will be a big step toward painless cross-platform compilation. It should also reduce one of the compilation speed bottlenecks, since I could

I saw this change come in yesterday: commit 572ad839e2f66eaa82ffc71b1061eb3d06a4d126 Author: Saleem Abdulrasool <compnerd at compnerd.org> Date: Thu Jun 15 20:39:58 2017 +0000 COFF: add support for lib mode usage When link is invoked with `/def:` and no input files, it behaves as if `lib.exe` was invoked. Emulate this behaviour, generating the import library from the

Greetings, I just found a bug in NewGVN: https://bugs.llvm.org/show_bug.cgi?id=35839 I noticed that it's off by default in clang. I'm going to turn it off by default in zig too, since it has a bug. What's the current status? Are we trying to move towards using it by default in llvm 6.0.0? 7.0.0? Regards, Andrew Kelley http://ziglang.org/ -------------- next part -------------- An

On Sun, Dec 11, 2016 at 7:31 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Thank you for this exciting update about LLD. > > I will start experimenting with using liblld in Zig (http://ziglang.org/) > instead of starting a child process to invoke the system linker. Once > liblld makes it into the various package managers out there, this will be a > big step toward

On Mon, Jun 3, 2019 at 8:04 PM Duncan Murdoch wrote: > I don't recall anyone asking for the zip in the 17 years after that > change, until now (though I haven't been paying attention lately, since > I retired from building the binaries a couple of years ago). > > If you think it's worthwhile to do it, then I don't think anyone would > object if you went ahead and

On 03/06/2019 9:16 p.m., Steven Penny wrote: > On Mon, Jun 3, 2019 at 8:04 PM Duncan Murdoch wrote: >> I don't recall anyone asking for the zip in the 17 years after that >> change, until now (though I haven't been paying attention lately, since >> I retired from building the binaries a couple of years ago). >> >> If you think it's worthwhile to do it,

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