[llvm-dev] [CMake] CMAKE_TOOLCHAIN_FILE and projects

[Chris Bieneman via llvm-dev]

There are a couple different facets relating to cross-compilation, and the level of support we have today varies based on what you're trying to do and which platforms you're doing it with.

If you want to build a set of tools that run on your build host and support targeting one or more targets, and want the runtime libraries built for those targets, we have the llvm/runtimes directory which can support building runtime libraries (compiler-rt, libunwind, libc++abi, libc++, etc), for n-different platforms from a single build configuration. You can look at the Fuscia build configurations to see how that works (https://github.com/llvm-mirror/clang/tree/master/cmake/caches <https://github.com/llvm-mirror/clang/tree/master/cmake/caches>).

If you want to build a compiler and runtimes for a cross target, things get a bit trickier.

In that situation you probably need a 2-stage build where you build the host compiler and target runtimes similar to how the Fuscia builds work, then you'll want to use that compiler and libraries to build the target compiler. You should be able to do that by providing a CMAKE_TOOLCHAIN_FILE to the second stage build configuration. We do support toolchain files for cross-targeting LLVM and Clang builds, and we have some documentation on it:

https://www.llvm.org/docs/GettingStarted.html#cross-compiling-llvm <https://www.llvm.org/docs/GettingStarted.html#cross-compiling-llvm>


Also for more general documentation on some of our more complicated builds see:

https://www.llvm.org/docs/AdvancedBuilds.html <https://www.llvm.org/docs/AdvancedBuilds.html>

-Chris

> On Dec 27, 2018, at 11:46 AM, Joel Winarske via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> I'm working on cross-compiling llvm and sub-projects to dynamically build Clang toolchain and associated libraries for an embedded project.
> 
> I'm starting with this mailing list, as I see the pattern using "config-ix.cmake" a common one; it's found in all the sub-projects.
> 
> For those that are not aware, in CMake the standard approach for dealing with unique toolchains, system roots, etc is through the use of  a CMAKE_TOOLCHAIN_FILE variable.  This toolchain file is used to define the compiler, system type, architecture, sysroot, etc.  It enables a simpler, and more versatile build script.
> 
> With tip of the tree on llvm and sub-projects now, when I use a toolchain file, I'm finding I have to make edits to the config-ix.cmake files.  The issue is related to re-defining CMAKE_SYSROOT and the use of; among others:
> 
>     set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nodefaultlibs")
> 
> When this flag is used in stand-alone cross-compiled builds (using toolchain file to set the CMAKE_SYSROOT), it causes all the subsequent flag checks to fail.
> 
> I think leveraging an implied CMake toolchain file for sub-projects should be the preferred solution for "projects", and it's a fairly minor change to accommodate.
> 
> Stand-alone cross-compiled example for libunwind, compiler-rt, libcxxabi, and libcxx here (This config requires edits to the associated config-ix.cmake files for this to work):
> 
>     https://github.com/jwinarske/flutter_embedded <https://github.com/jwinarske/flutter_embedded>
> 
> 
> Perhaps there is already a working solution to cross-compile the sub-projects from a single build invocation now?  I found when cross-compiling compiler-rt as part of the Clang build, it fails due to sysroot issues.  Something which the CMake toolchain file scenario would cleanly solve.  The end goal being, when I set the list LLVM_TARGETS_TO_BUILD to desired targets, one could expect cross-compiled bits (as applicable) for each sub-project.  This would greatly simplify building a toolchain config.
> 
> Perhaps I'm not clear on the current solution, and this already does what is needed for stand-alone cross-compiling?  Until convinced otherwise, I think there is room for improvement here, and am willing to donate time to address it.
> 
> 
> Cheers,
> Joel Winarske
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190104/66c9d8d4/attachment.html>