On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote:> If you want to build a clang version that target x86 and ARM on an x86 > machine and your actual compiler does not support compiling for ARM, you > have to use the just built clang. >Using the just-built-clang will only work if compiler-rt has access to each target's sysroot. Compiler-rt attempts to do this by stubbing out sysroots (see the SDKs directory), but I wonder how well that'll work. There's only one ARM backend, for example, but multiple ARM targets (i.e. arm-none-linux-gnueabi, arm-linux-androideabi). Does there need to be a separate compiler-rt for each target triple or can we get by with one per architecture? It feels like it has to be one per target triple, but it doesn't look to be implemented that way. I'm new to compiler-rt, but is it possible that its CMake and autotools builds are both broken for everything but the host target? Of course, if you are building a clang version that have to run on an other> target, you should use you current compiler. >We don't need a special case for this. You can run the just-built-clang on an emulator such as QEMU. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/5d7fd4a6/attachment.html>
On May 23, 2013, at 10:30 AM, Greg Fitzgerald <garious at gmail.com> wrote:> > On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > If you want to build a clang version that target x86 and ARM on an x86 machine and your actual compiler does not support compiling for ARM, you have to use the just built clang. > > Using the just-built-clang will only work if compiler-rt has access to each target's sysroot. Compiler-rt attempts to do this by stubbing out sysroots (see the SDKs directory), but I wonder how well that'll work. There's only one ARM backend, for example, but multiple ARM targets (i.e. arm-none-linux-gnueabi, arm-linux-androideabi). Does there need to be a separate compiler-rt for each target triple or can we get by with one per architecture? It feels like it has to be one per target triple, but it doesn't look to be implemented that way. I'm new to compiler-rt, but is it possible that its CMake and autotools builds are both broken for everything but the host target? > > > Of course, if you are building a clang version that have to run on an other target, you should use you current compiler. > > We don't need a special case for this. You can run the just-built-clang on an emulator such as QEMU.Perhaps I’m misunderstanding you. Are you suggesting using QEMU as part of the LLVM build process?> > -Greg > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/513a6caf/attachment.html>
Hi Jim,> Perhaps I’m misunderstanding you. Are you suggesting > using QEMU as part of the LLVM build process?Just for the case of building the runtime libraries for a cross-compiled version of clang. Another option is to have the compiler-rt build depend on a host build of clang. So when cross-compiling clang, we'd generate two clang builds: a target version to ship, and a throwaway host version that only exists to cross-compile compiler-rt. I think this second option is the more elegant one (less source dependencies), but is it possible in a single CMake build? The QEMU solution entertains the idea of pushing forward with just one cross-compiler and putting all projects in one big [parallel] build. But if the QEMU dependency is too impractical, then compiler-rt requires a pre-built host cross-compiler. If no one takes issue with that, is it safe to just ignore the compiler-rt build in "autotools vs CMake" debate? It means we'll need a build to invoke the two builds. Should we write that in Make or CMake? :) -Greg On Thu, May 23, 2013 at 1:51 PM, Jim Grosbach <grosbach at apple.com> wrote:> > On May 23, 2013, at 10:30 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > > On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org > > wrote: > >> If you want to build a clang version that target x86 and ARM on an x86 >> machine and your actual compiler does not support compiling for ARM, you >> have to use the just built clang. >> > > Using the just-built-clang will only work if compiler-rt has access to > each target's sysroot. Compiler-rt attempts to do this by stubbing out > sysroots (see the SDKs directory), but I wonder how well that'll work. > There's only one ARM backend, for example, but multiple ARM targets (i.e. > arm-none-linux-gnueabi, arm-linux-androideabi). Does there need to be a > separate compiler-rt for each target triple or can we get by with one per > architecture? It feels like it has to be one per target triple, but it > doesn't look to be implemented that way. I'm new to compiler-rt, but is it > possible that its CMake and autotools builds are both broken for everything > but the host target? > > > Of course, if you are building a clang version that have to run on an >> other target, you should use you current compiler. >> > > We don't need a special case for this. You can run the just-built-clang > on an emulator such as QEMU. > > > Perhaps I’m misunderstanding you. Are you suggesting using QEMU as part of > the LLVM build process? > > > -Greg > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/2494c78e/attachment.html>