On 23 May 2013, at 07:53, Owen Anderson <resistor at mac.com> wrote:>> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang > > Aren't there issues with tblgen needing to be compiled for the host even in the second round in this configuration?I am currently using the CMake build system to cross-build LLVM/Clang for MIPS. I have two build directories, one which builds for x86 and one for MIPS. The MIPS build directory is set up to use the compiler and tablegen from the host. There are a few minor issues, but nothing serious. Having to specify the location of llvm and clang TableGen separately seems redundant. It would be nice to just say 'here is my existing LLVM/Clang build directory, use everything from there (including the compiler)'. The more annoying problem is that for some reason, the LLVM CMake files don't respect CMake toolchain files - I didn't even think this was possible - so I need to manually specify all of the things that are specified in the toolchain file. I don't understand the compiler-rt issue. It can't be built with the just-built clang because that clang won't run on the build system. It has to build with the cross compiler. David
> The more annoying problem is that for some reason, the LLVM CMake files don't respect CMake toolchain files - I didn't even think this was possible - so I need to manually specify all of the things that are specified in the toolchain file.That's odd, they work for me. A couple of months ago there was some mismatch between what LLVM and CMake thought "HOST" meant which destroyed lit.site.cfg's usefulness, but I thought those issues had been fixed. And as I recall the toolchain built anyway. Do you also see the "make -j9 dies" issue? Tim. (P.S. Sorry for the duplicate David, I hit the wrong reply button).
Le 23 mai 2013 à 14:37, David Chisnall <David.Chisnall at cl.cam.ac.uk> a écrit :> On 23 May 2013, at 07:53, Owen Anderson <resistor at mac.com> wrote: > >>> build native clang >>> build next clang with some target that supplies a sysroot and a >>> -target option to the native clang >> >> Aren't there issues with tblgen needing to be compiled for the host even in the second round in this configuration? > > I am currently using the CMake build system to cross-build LLVM/Clang for MIPS. I have two build directories, one which builds for x86 and one for MIPS. The MIPS build directory is set up to use the compiler and tablegen from the host. There are a few minor issues, but nothing serious. Having to specify the location of llvm and clang TableGen separately seems redundant. It would be nice to just say 'here is my existing LLVM/Clang build directory, use everything from there (including the compiler)'. The more annoying problem is that for some reason, the LLVM CMake files don't respect CMake toolchain files - I didn't even think this was possible - so I need to manually specify all of the things that are specified in the toolchain file. > > I don't understand the compiler-rt issue. It can't be built with the just-built clang because that clang won't run on the build system. It has to build with the cross compiler.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. Of course, if you are building a clang version that have to run on an other target, you should use you current compiler. -- Jean-Daniel
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>