<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">So, while working on this I’ve found some cases where build-script-impl is a bit sloppy about naming: we use the term “deployment target” quite a lot, both when talking about hosts for the swift compiler and standard library targets.</div><div class=""><br class=""></div><div class="">This leads to weird parts of the script - like in testing, where we iterate STDLIB_DEPLOYMENT_TARGETS but skip everything which isn’t also a host. Somebody got confused between deployment targets. Or in the lipo step, where we attempt to merge libraries across different hosts for some reason.</div><div class=""><br class=""></div><div class="">There are other general logic holes - such as the swift build targets getting calculated once in some free-standing code, when really they should be calculated per-host, or executables being looked for in the current host build output (rather than the local host build output).</div><div class=""><br class=""></div><div class="">So I’ve cut away my specific cross-compiling edits from these more general fixes and created a PR for those changes: <a href="https://github.com/apple/swift/pull/2497" class="">https://github.com/apple/swift/pull/2497</a></div><div class=""><br class=""></div><div class="">I know it’s quite a big diff, and that cross-compilation isn’t a massive priority, but I’d really like to incorporate feedback and, if possible, get it merged as soon as possible. No parameters or output has been changed (e.g. the host-specific install locations aren’t in there), so for the case today where you don’t cross-compile the tools, everything should resolve as it does today.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Karl</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 11 May 2016, at 09:17, Karl <<a href="mailto:raziel.im+swift-users@gmail.com" class="">raziel.im+swift-users@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 10 May 2016, at 04:11, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’ve managed to cross-compile the swift tools for the Raspberry Pi from OSX.<div class=""><br class=""></div><div class="">I thought I’d share my changes. Branch is here: <a href="https://github.com/karwa/swift" class="">https://github.com/karwa/swift</a>. I’ll work on merging it soon.</div><div class=""><br class=""></div><div class="">The only real change we need is a bit more structure to the install locations. I want to install to a deployment-target specific subdirectory within INSTALL_DESTDIR. We need that if we have multiple sets of tools to install and packages to build. Installable-package also gets appended with the deployment target and “.tar”.</div><div class=""><br class=""></div><div class="">Does anybody (or any bots) install directly from the build script? Would it be a lot of trouble to give install-destdir and install-symroot a bit of structure?</div><div class=""><br class=""></div><div class="">clang, swift, stdlib, the GlibC overlay all work (although I still need to add a step which regenerates glibc.modulemap - right now you’ll have to find/replace to take your sysroot out of it). LLBuild works. Foundation doesn’t cross-compile just yet, but I built it natively with the resulting swift compiler and clang. The problem seems to be fixable by tweaking the clang headers inside of lib/swift, so I’m not sure if maybe my system headers are a bit wonky. Swiftpm depends on Foundation, and LLDB was having some trouble finding libraries for python.</div><div class=""><br class=""></div><div class="">Invoke with:</div><div class=""><br class=""></div><div class=""><div class="">../swift/utils/build-script -R \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--llbuild \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--ios \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--installable-package=“${out_files}/swift-3.0" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--install-destdir=“${out_files}/output" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--install-symroot=“${out_files}/debug-output" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-- \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--llvm-install-components="clang;clang-headers;libclang;libclang-headers" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--swift-install-components="compiler;stdlib;sdk-overlay;clang-builtin-headers;editor-integration;sourcekit-xpc-service" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--darwin-toolchain-name="swift-3.0" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--darwin_toolchain_display_name="local.swift.3" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--darwin_toolchain_bundle_identifier="local.swift.3" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--toolchain_prefix="swift3.xctoolchain" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--darwin_toolchain_alias="local" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--install-swift="1" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--install-llbuild="1" \</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>--install-prefix="/usr" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--cross-compile-tools-deployment-targets=linux-armv7 \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--cross-compile-sysroot="${sysroot}" \</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>--cross-compile-toolchain-bin="${toolchain}” \</div></div><div class=""><br class=""></div><div class="">where ${out_files} is going to end up like this:</div><div class=""><br class=""></div><div class="">— swift-3.0-macosx-x86_64.tar</div><div class="">— swift-3.0-linux-armv7.tar</div><div class="">— output/</div><div class=""> | — macosx-x86_64/</div><div class=""> | — swift3.xctoolchain/</div><div class=""> | — Info.plist</div><div class=""> | — usr/ (etc)</div><div class=""><div class=""> | — linux-armv7/</div><div class=""> | — usr/ (etc)</div></div><div class=""><br class=""></div><div class=""><div class="">${toolchain}:</div><div class=""><br class=""></div><div class="">Built from: <a href="https://launchpad.net/gcc-arm-embedded/5.0/5-2015-q4-major" class="">https://launchpad.net/gcc-arm-embedded/5.0/5-2015-q4-major</a></div><div class="">Edit install_toolchain.sh and add “--enable-gold” to the binutils flags</div><div class="">Also in install_common.sh, charged TARGET to "arm-linux-eabi”, but not sure that’s necessary.</div><div class="">Give the path to the unprefixed versions of the tools, e.g: “/cc-toolchain/gcc-arm-none-eabi-5_2-2015q4/install-native/arm-linux-eabi/bin"</div><div class=""><br class=""></div><div class="">${sysroot}:</div><div class=""><br class=""></div><div class="">Created using this script. Requires dpkg-deb (can be installed with brew): <a href="https://gist.github.com/karwa/c73f9fd2768c96f6871be4aae152b264" class="">https://gist.github.com/karwa/c73f9fd2768c96f6871be4aae152b264</a></div><div class=""><div class=""><br class=""></div><div class="">./make_sysroot.py --distro debian --version jessie --arch armhf --install sysroot.armhf.debian.jessie</div><div class=""><br class=""></div><div class="">Let me know how it goes.</div><div class=""><br class=""></div><div class="">Karl</div><div class=""><br class=""></div></div></div></div></div></blockquote></div><br class=""><div class="">My apologies, the correct binutils target for the RPi is “arm-linux-gnueabihf”, not “arm-linux-eabi”, and you do have to change it before building the toolchain.</div><div class=""><br class=""></div><div class="">Karl</div></div></div></blockquote></div><br class=""></body></html>