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 x86_64-unknown-linux-musl build support #1517

Closed
wants to merge 3 commits into from

Conversation

martell
Copy link
Contributor

@martell martell commented Sep 26, 2018

Closes #1053

@bors
Copy link
Contributor

bors commented Oct 4, 2018

☔ The latest upstream changes (presumably 6d47fed) made this pull request unmergeable. Please resolve the merge conflicts.

@strfry
Copy link

strfry commented Oct 17, 2018

@martell Please regard my additional commit 54b50f5 in #1527 .
The Dockerfile must describe a normal glibc-distro with musl-capabilities for this build system to work.

What else is needed to make rustc appear in x86_64-unknown-linux-musl flavor?

@martell
Copy link
Contributor Author

martell commented Oct 17, 2018

Hey @strfry,

First, thanks for the help :)
I thought no one was interested in this but me.

The Dockerfile must describe a normal glibc-distro with musl-capabilities for this build system to work.

EDIT: I see the error now.
bash does not come by default on alpine.
I'll update.

+docker run --entrypoint bash --user 2000:2000 --volume /home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:/travis-rust:ro --volume /home/travis/build/rust-lang-nursery/rustup.rs:/src:ro --volume /home/travis/build/rust-lang-nursery/rustup.rs/target:/src/target --workdir /src --env TARGET=x86_64-unknown-linux-musl --env SKIP_TESTS=1 x86_64-unknown-linux-musl ci/run-docker.sh
container_linux.go:265: starting container process caused "exec: \"bash\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:265: starting container process caused "exec: \"bash\": executable file not found in $PATH".
ERRO[0000] error waiting for container: context canceled

What else is needed to make rustc appear in x86_64-unknown-linux-musl flavor?

I'm not sure, I upstreamed a few commits from musl / alpine needed changes into llvm 5.0 which was 2 releases ago now in the hopes that later we could get rustup support for alpine.
I think for build systems making minimal alpine rust containers it would be better than using the package manager.

@alexcrichton could you weigh in with some direction/feedback?

Best,
Martell

@strfry
Copy link

strfry commented Oct 18, 2018

@martell ,

I started out with just adding bash (and then later rustc and cargo), but the way this is supposed to work is that the rustc is passed in through a Docker volume from the Travis host system. And that doesn't work when the container is a different architecture than the host distro.
What finally worked was to adapt one of the other Dockerfiles and install musl-tools a as the cross-compiler. The build will try call musl-gcc at some point, seems like someone already figured this out ;)

The other part i ment is getting rust itself to compile x86_64-musl as a host architecture, so that it's provided for rustup to download.
I opened rust-lang/rust#55163 and ran into some issues.

@alexcrichton
Copy link
Member

@martell I think it's probably not worth doing this until we get a musl host rustc working, otherwise this rustup won't have anything to download! When it works though it'll be easiest to compile a static rustup here, just using cross compilation from a glibc environment to x86_64-unknown-linux-musl which will produce a statically linked binary

@kinnison
Copy link
Contributor

@martell Do you think you want to keep this PR open for now, or should we close it off and perhaps just leave #1053 to track this?

@dwijnand
Copy link
Member

Seeing as #1053 is blocked on upstream rust-lang/rust#57439, I think it makes sense to close this PR in the meantime. Please note that a closed PR isn't a rejected PR, the work here can be reused and resubmitted.

@martell
Copy link
Contributor Author

martell commented Jan 30, 2019

Sorry for the delay, I'll close this for now until the host support has been resolved.

@martell martell closed this Jan 30, 2019
@martell martell reopened this Mar 16, 2019
@mati865
Copy link
Contributor

mati865 commented Mar 18, 2019

IIUC this needs cfg similar to the one for MIPS:
https://github.com/rust-lang/rustup.rs/blob/819ddda6b7fc1f18884f027f646cd8714f8c4e9a/src/dist/dist.rs#L178

EDIT: https://github.com/rust-lang/rustup.rs/blob/master/rustup-init.sh would also need to detect if host is musl based. I tested it on Void Linux and Alpine Linux and checking output of ldd --version for musl looks reasonable:

$ ldd --version
musl libc (x86_64)
Version 1.1.21
Dynamic Program Loader
Usage: ldd [options] [--] pathname

@martell martell force-pushed the alpine-x86_64 branch 2 times, most recently from 6f06325 to 4549859 Compare March 23, 2019 05:12
@martell
Copy link
Contributor Author

martell commented Mar 23, 2019

@alexcrichton soft ping

@martell martell force-pushed the alpine-x86_64 branch 2 times, most recently from 4bc6899 to 56b721e Compare March 23, 2019 06:21
@alexcrichton
Copy link
Member

Ah oops thanks for the ping. I'm not sure the container will work here though since it's primarily used with glibc toolchains, although you can edit .travis.yml to see the failure on the PR. Could the build be configured to do a cross build from a glibc toolchain to a musl toolchain?

.travis.yml Outdated Show resolved Hide resolved
@martell martell force-pushed the alpine-x86_64 branch 2 times, most recently from f8f4803 to 44ddbe9 Compare May 19, 2019 00:42
@martell
Copy link
Contributor Author

martell commented May 19, 2019

Finally got some time this weekend to have another look.

@alexcrichton I believe this should be mergeable now.
When you approve I will drop 44ddbe9 from the PR

Thanks again for the suggestion @rye.

@rye
Copy link

rye commented May 19, 2019

@martell, no problem, and thank you for doing this! It at least certainly seems that #3396.2 (musl build) was successful and did use the appropriate target! Can't wait to use rustup in my Alpine environments soonish. 😄

Copy link
Contributor

@kinnison kinnison left a comment

Choose a reason for hiding this comment

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

I'm not in a position to review the musl-specific bits, but one comment I do have is regarding the docker machine.

@lzutao put a lot of effort into allowing us to reuse the Rust compiler docker images in order to ensure that we were matching libcs etc wherever possible. Is there a suitable rust-compiler docker for musl to save the creation of the docker from ubuntu?

@tesuji
Copy link
Contributor

tesuji commented May 19, 2019

@kinnison Yes, Rustc has dist-x86_64-musl dockerfile. I haven't tested it yet
but it's worth a try.

@kinnison
Copy link
Contributor

@lzutao Do you think you could look at what's been done on this PR and then see if you can come up with a proposed patch to reuse the rustc docker if appropriate?

@alexcrichton
Copy link
Member

This all looks good to me, thanks @martell!

@kinnison FWIW musl is pretty special in that it doesn't require the same docker containers as other targets. The main difference is that the musl target is by default statically linked instead of having a dependency on a dynamically linked libc. For glibc platforms you need a special toolchain for targeting a really old glibc (which is our goal in rust-lang/rust and what rustup wants to mirror), but for musl there's no need since any toolchain can produce a workable binary!

In that sense this should be good to go IMO w/o docker changes.

@martell
Copy link
Contributor Author

martell commented May 20, 2019

Awesome, I'm happy to do any docker changes as a follow up if anyone wishes.
I did actually try FROM rust-x86_64-unknown-linux-musl but that did not exist.
We can create one if needed. Anyone have a specific issue they want to create for this?

@alexcrichton I do not have permission to merge.
I did however remove the ci testing commit as promised.
Can you merge?

Copy link
Contributor

@tesuji tesuji left a comment

Choose a reason for hiding this comment

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

The PR might still fail because of missing sccache.

src/dist/dist.rs Outdated Show resolved Hide resolved
src/dist/dist.rs Outdated Show resolved Hide resolved
@alexcrichton
Copy link
Member

Note that I'm personally just commenting here, I'm leaving the final review up to @kinnison

@kinnison
Copy link
Contributor

If there's no value in using the rustc docker for now, then I'll wait on the sccache comment responses before I make a decision.

@martell
Copy link
Contributor Author

martell commented May 22, 2019

@kinnison done :)
Same deal as before, once approved I will remove the travis change commit.
Ahh damn, I was a few hours late to make the next rustup release :/

@tesuji
Copy link
Contributor

tesuji commented May 23, 2019

@martell You could use ci/docker/armv7-unknown-linux-gnueabihf/Dockerfile as an example to
install sccache.

@kinnison
Copy link
Contributor

The appveyor failure is spurious (possibly due to too many parallel tests at once?)

@tesuji
Copy link
Contributor

tesuji commented May 23, 2019

I pushed some changes to my branch. You could cherry-pick it to your PR.

Copy link
Contributor

@tesuji tesuji left a comment

Choose a reason for hiding this comment

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

Edit ci/cloudfront-invalidation.txt and add musl targets.

@kinnison
Copy link
Contributor

Edit ci/cloudfront-invalidation.txt and add musl targets.

It's not entirely clear if the cloudfront invalidation would be necessary, but it can't hurt to have it amended.

@tesuji
Copy link
Contributor

tesuji commented May 29, 2019

Ok, I take it at #1882

@martell
Copy link
Contributor Author

martell commented May 29, 2019

Thanks @lzutao

@martell martell closed this May 29, 2019
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.

Promote x86_64-unknown-linux-musl from target to host toolchain
9 participants