Enable cross-compiling #1398
Enable cross-compiling #1398
Conversation
|
Why not use |
|
It was more work to figure out how to install/run debootstrap on OS X to do what I wanted, and provide easy-to-follow instructions, than to write this script. Would it be better if I just removed the script and hosted it myself, and suggest that users provide their own sysroot? |
froody
force-pushed
the
cross-compile
branch
2 times, most recently
from
246850b
to
dd4f01a
Compare
|
debootstrap is the official ways to create sysroots for Debian and derivatives. I'd rather we don't promote a hacky way. |
|
If someone needs to run debootstrap on OS X, they can easily use a VM, for example. |
|
Ok, I removed my script, any thoughts on the rest of the patch? |
froody
force-pushed
the
cross-compile
branch
from
dd4f01a
to
4e17cb9
Compare
|
@gribozavr ping? |
|
I'm having a bit of trouble getting this pull request to work. I've used your pull request as a patch against the 2/26 swift snapshot, and built up a set of scripts according to your instructions: https://github.com/cellularmitosis/swift-build-scripts UPDATE: ran this again from scratch, different error: I noticed that indeed, |
|
Are you building this on a Linux machine? It looks like it from this log. I haven't accounted for that in this patch, but can. You need to add "linux-armv7" to the STDLIB_DEPLOYMENT_TARGETS for your host (see where STDLIB_DEPLOYMENT_TARGETS is first assigned in build-script-impl) and disable the host build somehow (an easy hacky way to see if it works is to comment out the "host" stdlib deployment target, so STDLIB_DEPLOYMENT_TARGETS=("linux-armv7"). I'll work on getting linux-x86_64 cross-compiling linux-armv7 into this patch too. |
|
That would be amazing if you could also work on linux-x86_64! I'll also try your suggested workaround in the mean time. |
| targets_group.add_argument( | ||
| "--cross-compile-targets", | ||
| help="The cross-compliation targets. The Swift stdlib will be built for" | ||
| "these targets using the host-target LLVM and Clang", |
There was a problem hiding this comment.
This description does not sound correct to me. We can't build the Swift standard library using LLVM and Clang, we need a Swift compiler.
froody
force-pushed
the
cross-compile
branch
from
4e17cb9
to
928c4b7
Compare
|
FYI, I’m waiting to hear from @cellularmitosis that this has worked for him before proceeding to evaluate it. |
|
Invoking the build-script-impl twice from the top-level build-script is not a good solution either. build-script-impl already has support for invoking cmake multiple times, it should be able to figure out everything. |
|
I'll fire off another build this evening. update (6:53pm): building using the following invocation: update: 8:02pm: Looks like it failed in the same way: I'm invoking this script: https://github.com/cellularmitosis/swift-build-scripts/blob/master/go-linux-armv7.sh Which builds against the @froody Did you still want me to do the manual modifications you mention above? How should I invoke this build? Thanks, |
froody
force-pushed
the
cross-compile
branch
3 times, most recently
from
08799ad
to
53a72a5
Compare
|
Updated to fix linux build. @cellularmitosis: I successfully built on ubuntu 15.10/x86_64 with |
|
Thanks! Rebuilding. I'll update this comment when the build finishes. update @froody the build failed on step 7 of building the standard lib. I'm guessing this was the first linking step. It looks like it couldn't find This was invoked via https://github.com/cellularmitosis/swift-build-scripts/blob/master/build-linux-armv7.sh I'm using the toolchain from https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update/+download/gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 I performed the following grep, perhaps it is useful? |
|
@cellularmitosis Can you change your script to set: toolchain="`pwd`/stage/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-"and delete the |
|
Ah, now I understand. I'll try again. update @froody A different failure: CMakeError.log contains: It looks like the relevant error is: Should it be using I just realized that the manner in which I'm copying in Should I rename it to |
|
Hey @froody, In the interest of speeding things up here, in an effort to more closely mirror the setup which has already worked for you, I ditched Debian in favor of Ubuntu 14.04, installed clang-3.6, gcc-arm-linux-gnueabi, and rebuilt. I ran into the following error: (this is in a VirtualBox VM). |
|
@cellularmitosis I'm confused as to how you got this. I think what's missing is the "-target", but that should have been set by CMAKE_C_COMPILER_TARGET. I'm assuming you deleted the |
|
@froody sure, after that failure I started a new build from scratch, to make sure the failure was reproducible. I'll post the results when I get home from work today. update I forgot to give the VM sufficient swap space and the build failed during the linking phase. That's a great sign! I've increased the swap space and am building again. |
|
@froody the from-scratch build failed: Here's the entire build process output: https://gist.github.com/cellularmitosis/cc7fcb54a8e934c4df36 |
|
I get the same error, on OSX trying to build for Debian using the sysroot/toolchain script in swift-build-scripts. |
|
Cross-compilation is something I'm extremely interested in: #1157 and other armv7 pull requests took a long time to test because contributors had to compile for hours on underpowered machines to get test results. I'm very excited for this pull request--thanks, @froody! I tried this out myself and managed to get everything working on OS X, following the steps in
With the above I've successfully built the stdlib for linux-armv7 from an OS X machine: Exciting stuff! This would have made development on #1442 much simpler. @dabrahams It'd be awesome if we could discuss whether this could be merged, I think it'd help a lot of people out (myself included). |
|
@modocache One thing that the PR is not doing correctly now is invoking build-script-impl twice. build-script-impl already has support for cross-compilation, and this addition should fit into the existing scheme, so that we don't have two codepaths doing essentially the same, but slightly differently. |
|
@modocache I’ll take a look again after you’ve addressed that double-invocation-of-build-script issue |
Allow using and OS X build of swift to build libraries and binaries for another platform, only linux-armv7 is supported in this patch. Doesn't currently support building the tools (llvm, swiftc) or the tests for linux-armv7. * Added --cross-compile-stdlib-targets to build-script * Added --cross-compile-sysroot to build-script-impl * Added --cross-compile-toolchain-bin to build-script-impl * Set -resource-dir when cross-compiling * Use BUILD_HOST_TARGET instead of HOST_TARGET, allow it to be empty when cross-compiling to just build cross target * Derive PKG_CONFIG_PATH from --cross-compile-sysroot to allow find_package to work * Skip cmark and llvm builds completely when --native-*-tools-path flags are set See instructions in cmake/modules/Toolchain-linux-arm.cmake. To build linux-armv7 on osx run: ./utils/build-script -R --cross-compile-stdlib-targets linux-armv7 -- --cross-compile-sysroot=$MY_SYSROOT --cross-compile-toolchain-bin=$MY_TOOLCHAIN_BIN
|
@karwa Can you give me steps to recreate your sysroot? @gribozavr @dabrahams I've addressed the double-invocation-of-build-script issue and updated the commit message/PR description |
* Demux uname info into a list of stdlib_deployment_targets in python * Generate list of allowed stdlib_cross_targets based on host info
|
OK, I've got it to compile on OSX. I compiled a new toolchain, just grab the source from here and edit the binutils build script to enable gold. I used the build output of that as my toolchain, but clang still couldn't resolve arm-none-eabi-ld.gold with the -fuse=gold option. So I used the non-prefixed toolchain path (i.e. /arm-none-eabi/bin/ld.gold instead of /bin/arm-none-eabi-ld.gold) and that seemed to help it find everything. That means you need to change Toolchain-linux-arm.cmake and set AR path with "${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}/ar". |
|
What happend to this PR? |
|
@stefanstefan2001 I'm trying to split it up (see #2187) and get cross-compilation merged. It seems like a sticking point is the multiple invocations of |
|
This PR has been dormant for a long time. Is it still relevant? |
|
@DougGregor It's still relevant as long as build performance is cheaper to achieve on some platforms than on others. |
|
Any update on when this might be merged? |
|
Can someone rebase this onto master and fix the conflicts, and we'll make sure to review it and get it merged ASAP? |
|
Some of the changes already got merged in. I've been maintaining a branch which contains the rest: https://github.com/karwa/swift Basically the only things not yet merged are the CMake toolchain file and the pkg-config lookup in The idea was to refactor some of these options/data in to some kind of "cross-compilation bundle" which would not only be used by the build-script to build the compiler, but also understood by the compiler in order to cross-compile Swift executables later. The problem is that those bundles would need to contain the compiler's external dependencies, which are floating, platform-specific and not documented in a structured way for tooling. Basically, we would need to develop a kind of mini package manager. So since then I've been (casually) looking at using a C++ package manager instead, like https://github.com/ruslo/hunter or something. |
|
Does this PR still represent the state of cross-compiling in Swift? If so, is there any documentation on how to use it? I've been trying to build a cross-compiler to Raspberry Pi. I've grabbed @karwa's fork from https://github.com/karwa/swift and rebased his patches to master, put together a toolchain and a sysroot, and built with this command: Eventually I got this error: I'd be grateful for pointers from anybody who's made this work. Thanks! |
|
Since @karwa is maintaining a more up-to-date fork, and this pull request has fallen behind the more comprehensive efforts to enable cross-compilation, I'm going to close it. Somebody should take a look at the state of the smaller pull requests that have been split off of this one and @karwa's branch and give us a more modern pull request. |
Build both host and target toolchains in 5.3 branch
Allow using and OS X build of swift to build libraries and binaries for another
platform, only linux-armv7 is supported in this patch. Doesn't currently support
building the tools (llvm, swiftc) or the tests for linux-armv7.
cross-compiling to just build cross target
work
See instructions in cmake/modules/Toolchain-linux-arm.cmake. To build
linux-armv7 on osx run:
./utils/build-script -R --cross-compile-stdlib-targets linux-armv7 -- --cross-compile-sysroot=$MY_SYSROOT --cross-compile-toolchain-bin=$MY_TOOLCHAIN_BIN