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.

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

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,

I have been using this project with great success to achieve this : https://github.com/mstorsjo/llvm-mingw It generates a linux-based windows cross-compiler with clang, libc++, etc. I was able to build a large part of Qt with it afterwards for instance. Best, Jean-Michaël On 06/11/2018 04:21, Petr Hosek via llvm-dev wrote: > I've tried building libc++ for Windows on Linux by setting

I suspect mingw is going to be incompatible with Petr’s needs. Adding Nico as he probably does the most cross compiling. I did it a little several weeks ago, just not with libc++, and I don’t remember running into any problems. One thing that’s not clear to me is why the resource compiler is even being invoked at all On Tue, Nov 6, 2018 at 5:46 AM Martin Storsjö via llvm-dev < llvm-dev at

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 03/10/2014 06:56 PM, Ralph Giles wrote: > On 2014-03-10 2:47 PM, Jonathan Lennox wrote: >> If I add --disable-asm to the build, it builds correctly. >> >> Does anyone have experience with Apple assembler directives to know >> what?s the best way to fix this? I assume the Perl script to generate >> the assembler file is going to need to be modified somehow. >

Hi everyone, (Sorry if I'm asking at the wrong mail listing, but compiler-rt page tells I'd better write on llvm-dev rather than cfe-dev/cfe-users.) I've just built LLVM/Clang+Compiler-rt (Compiler-rt is put inside llvm/projects folder) and tried the -fsanitize option. But strangely the link failed since it cannot find *libclang_rt.san-x86_64.a*. The error message is as

Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re

Just a note about this: >I like this. I hope you don't mind if I borrow some of these ideas to >play with. C_COMPILER_WORKS is something I've never heard of. I'm also working on building a clang-based toolchain from scratch. To avoid CMake bailing out when a binary can't be linked, I use: -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY Along with:

Ah ha! I found crash reports: green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash Process: mmap_stress.cc.tmp [95010] Path: /Users/USER/*/mmap_stress.cc.tmp Identifier: mmap_stress.cc.tmp Version: 0 Code Type: X86-64 (Native) Parent Process: bash [95004] User ID:

On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote: > I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. > > There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at

I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at bugs.llvm.org: 1) libclang_rt It looks like the cmake build is missing some runtime

So, is there an agreement now? In particular, is it fine to have the asan run-time for linux x86/x86_64 at lib/clang/linux/TC.getArchName())/libclang_rt.asan.a ? Thanks, --kcc On Mon, Nov 28, 2011 at 12:53 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hey Chandler, > > We already have a certain precedent for how we do this on Darwin. The > current library set is: > --

Hey Chandler, We already have a certain precedent for how we do this on Darwin. The current library set is: -- $ find lib/clang/3.1/lib lib/clang/3.1/lib lib/clang/3.1/lib/darwin lib/clang/3.1/lib/darwin/libclang_rt.10.4.a lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a lib/clang/3.1/lib/darwin/libclang_rt.ios.a

Please excuse hobbiest-level question. Darwin 11+ enables thread_local variables using system-level supports. I have an interest in enabling TLS on darwin < 11 using emulated-tls. This can be enabled with a few modest patches: ========================== --- a/include/llvm/ADT/Triple.h.orig 2018-10-02 17:38:10.000000000 -0700 +++ b/include/llvm/ADT/Triple.h 2018-10-02 17:38:58.000000000

Hi, I am using clang++3.9 to build a simple program with both CFI and safe-stack. I am getting linker errors when combining -fsanitize=safe-stack, -fsanitize=cfi, and -fno-sanitize-trap=all. Combining safe-stack and CFI without -fno-sanitize-trap=all works as expected. It looks like clang is attempting to link in two compiler-rt libraries, one for ubsan and one for safestack, and this causes

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

> When I run 'djpeg' on JellyBean, ASan reports the error message below. > > ==28210==Shadow memory range interleaves with an existing memory > mapping. ASan cannot proceed correctly. ABORTING. Got figured out. I needed to use TARGET_LDFLAGS. LOCAL_LDFLAGS seems to be ignored in my clang build. LOCAL_CFLAGS += -fsanitize=address TARGET_LDFLAGS +=-fsanitize=address -target