<div style="white-space:pre-wrap">I'm in discussions about this with some others over at<br><a href="https://github.com/SwiftAndroid/swift/issues/13">https://github.com/SwiftAndroid/swift/issues/13</a><br><br>Basically the Swift build process as is isn't made for arbitrary cross-compiling. The iOS cross-compiling from OSX relies on some happy accidents, e.g. that they're all Apple platforms, and isn't robust. So we're discussing some alternatives that would eventually also benefit your porting effort.<br><br>Out of interest, have you found a version of clang that compiles from your host machine to an arm-Linux target? Or delved into the source in order to make your own? I'd be interested in cross-compiling for Raspberry Pi too but haven't looked into toolchains yet.<br><br>Geordie<br></div><div class="gmail_quote"><div dir="ltr">Tom Gall <<a href="mailto:tom.gall@linaro.org" target="_blank">tom.gall@linaro.org</a>> schrieb am Mo., 18. Jan. 2016 um 22:07:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cool!<br>
<br>
I was just starting a similar exercise but using x86-64 linux as the<br>
host since I've managed to get swift building and running on my<br>
arm-linux box.<br>
<br>
Cheers!<br>
<br>
On Mon, Jan 18, 2016 at 1:03 PM, Geordie Jay via swift-dev<br>
<<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
> I have just pushed a branch to the SwiftAndroid repo that is at the stage of<br>
> correctly compiling the swift toolchain and stdlib objects for android-armv7<br>
> and macosx-x86_64 (as verified using nm from the different toolchains):<br>
> <a href="https://github.com/SwiftAndroid/swift/tree/osx-crosscompile" rel="noreferrer" target="_blank">https://github.com/SwiftAndroid/swift/tree/osx-crosscompile</a>. The problem is<br>
> it fails at the linker stage.<br>
><br>
> Basically the OSX linker doesn't understand the “—sysroot” option (See<br>
> AddSwift.cmake:59). Up until that point though (throughout the compiling<br>
> stage), we need that option because otherwise the Android components attempt<br>
> to use OSX /usr/include, which throws all sorts of errors because of wrong<br>
> architecture etc. Why it fails to compile when I remove the “—sysroot”<br>
> option, but also fails _with_ it in the link stage will probably be key to<br>
> fixing this. Again, it seems that what we really need to do is use the<br>
> Android linker, not the Xcode one.<br>
><br>
> I'm going to try figure out how to do that tomorrow but not confident I’ll<br>
> get far given my limited experience with this.. This work may also be of<br>
> interest to the Raspberry Pi / BeagleBoard folks, would also love to hear<br>
> some opinions about how to solve the CMAKE_SYSTEM_NAME problem, that will<br>
> also affect cross-compilation for those uses. In any case, any hints or<br>
> collaborators would be most welcome.<br>
><br>
> Geordie<br>
><br>
><br>
> _______________________________________________<br>
> swift-dev mailing list<br>
> <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Regards,<br>
Tom<br>
<br>
"Where's the kaboom!? There was supposed to be an earth-shattering<br>
kaboom!" Marvin Martian<br>
Director, Linaro Mobile Group<br>
Tech Lead, GPGPU<br>
Linaro.org │ Open source software for ARM SoCs<br>
irc: tgall_foo | skype : tom_gall<br>
</blockquote></div>