Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add script to build Ubuntu cross compilation toolchain #1099

Merged
merged 2 commits into from
Apr 19, 2017

Conversation

weissi
Copy link
Contributor

@weissi weissi commented Apr 19, 2017

To cross compile a binary, you will need a cross compilation toolchain which consists of the toolchain itself and an SDK. For example compiling an iPhone binary from your Mac will use /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.3.sdk or similar. If you want to compile a Swift binary for say Ubuntu Xenial on your Mac, you'll need the following pieces of software

  • a compiler being able to cross compile ✅ (swiftc and clang are able to do that)
  • the basic Swift libraries (like libswiftCore) for Ubuntu ✅ (that's part of the Swift distribution for Ubuntu)
  • an SDK for Ubuntu Linux ✅ (that can be assembled from the .deb packages available from Ubuntu)
  • an ELF linker that runs on macOS ✅ (the gold linker from the GNU binutils can be compiled on macOS)

In other words, all the pieces of software are available for free online, they just need to be assembled in the correct way. This script is an example on how you can do that for Ubuntu Xenial.

Example use:

Utilities/build_ubuntu_cross_compilation_toolchain /tmp/ ~/Downloads/swift-3.1-RELEASE-osx.pkg ~/Downloads/swift-3.1-RELEASE-ubuntu16.04.tar.gz

This should (after quite some time) result in a file called /tmp/cross-toolchain/ubuntu-xenial-destination.json which you can hand to SwiftPM using the --destination flag introduced in #1098 . An example for that is

cd my-spm-project
swift build --destination /tmp/cross-toolchain/ubuntu-xenial-destination.json

which should result in a binary for Linux 😃

$ file .build/debug/MySPMTestProgram
.build/debug/SwiftHttpServerTest: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

@aciidgh
Copy link
Contributor

aciidgh commented Apr 19, 2017

I think we should add the usage instructions somewhere, maybe at top of the file or as a separate markdown file.

@weissi
Copy link
Contributor Author

weissi commented Apr 19, 2017

added that to the usage output of the script itself.

@aciidgh
Copy link
Contributor

aciidgh commented Apr 19, 2017

@swift-ci please smoke test

1 similar comment
@aciidgh
Copy link
Contributor

aciidgh commented Apr 19, 2017

@swift-ci please smoke test

Copy link
Contributor

@ddunbar ddunbar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM... in conjunction with this can we get some internal document describing the keys we accept in the destination JSON file (in our internal docs somewhere) and then have this script point to that as the canonical place to describe what this is

fi
}

function fix_glibc_modulemap() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something we expect to always have to do, or should there be a bug tacking eliminating the need for it? (i.e., is it something we fix in Swift)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ddunbar that's a very good question. I think that's a bug in Swift.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants