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

cc: update to 1.0.10 #50103

Closed
wants to merge 1 commit into from
Closed

cc: update to 1.0.10 #50103

wants to merge 1 commit into from

Conversation

mixi
Copy link
Contributor

@mixi mixi commented Apr 20, 2018

This is needed when compiling a dynamically linked rustc (as is required for rustc) for -musl targets with the internal llvm compiled as part of the rustc build process. See rust-lang/cc-rs#307.

@pietroalbini pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 20, 2018
@pietroalbini
Copy link
Member

Thanks for this PR! Assigned a reviewer for it.

@alexcrichton
Copy link
Member

Thanks for the PR! This is actually also happening as a part of #50056 and the update of cc causes the build to fail, so I'm going to apply the requisite fixes in that PR as well

@bors
Copy link
Contributor

bors commented Apr 21, 2018

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

@mixi
Copy link
Contributor Author

mixi commented Apr 21, 2018

This is obsolete with #50056 landed. (Why didn't you already close this when telling me it is a duplicate?)

@mixi mixi closed this Apr 21, 2018
bors added a commit that referenced this pull request May 11, 2018
Use the correct crt*.o files when linking musl targets.

This is supposed to support optionally using the system copy of musl
libc instead of the included one if supported. This currently only
affects the start files, which is enough to allow building rustc on musl
targets.

Most of the changes are analogous to crt-static.

Excluding the start files is something musl based distributions usually patch into their copy of rustc:
  - https://github.com/alpinelinux/aports/blob/eb064c8/community/rust/musl-fix-linux_musl_base.patch
  - https://github.com/voidlinux/void-packages/blob/77400fc/srcpkgs/rust/patches/link-musl-dynamically.patch

For third-party distributions that not yet carry those patches it would be nice if it was supported without the need to patch upstream sources.

## Reasons
### What breaks?
Some start files were missed when originally writing the logic to swap in musl start files (gcc comes with its own start files, which are suppressed by -nostdlib, but not manually included later on). This caused #36710, which also affects rustc with the internal llvm copy or any other system libraries that need crtbegin/crtend.

### How is it fixed?
The system linker already has all the logic to decide which start files to include, so we can just defer to it (except of course if it doesn't target musl).

### Why is it optional?
In #40113 it was first tried to remove the start files, which broke compiling musl-targeting static binaries with a glibc-targeting compiler. This is why it eventually landed without removing the start files. Being an option side-steps the issue.

### Why are the start files still installed?
This has the nice side-effect, that the produced rust-std-* binaries can still be used by on a glibc-targeting system with a rustc built against glibc.

## Does it work?
With the following build script (using [musl-cross-make](https://github.com/richfelker/musl-cross-make)): https://shadowice.org/~mixi/rust-musl/build.sh, I was able to cross-compile a musl-host musl-targeting rustc on a glibc-based system. The resulting binaries are at https://shadowice.org/~mixi/rust-musl/binaries/. This also requires #50103 and #50104 (which are also applied to the branch the build script uses).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants