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

Disable auto-detection of libxml2 when compiling llvm. #50104

Merged
merged 1 commit into from
Apr 20, 2018

Conversation

mixi
Copy link
Contributor

@mixi mixi commented Apr 20, 2018

This broke cross-compiling rustc with internal llvm (with both the host and target being executable on the machine), because llvm's build system detected libxml2 on the host, therefore auto-enabled libxml2 support, but wouldn't compile as the target didn't have libxml2 installed.

@pietroalbini
Copy link
Member

Thanks for this PR! Assigned a reviewer for it.

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

Hm, this seems fine but r? @alexcrichton

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Apr 20, 2018

📌 Commit b92e6c3 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 20, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Apr 20, 2018
Disable auto-detection of libxml2 when compiling llvm.

This broke cross-compiling rustc with internal llvm (with both the host and target being executable on the machine), because llvm's build system detected libxml2 on the host, therefore auto-enabled libxml2 support, but wouldn't compile as the target didn't have libxml2 installed.
bors added a commit that referenced this pull request Apr 20, 2018
Rollup of 7 pull requests

Successful merges:

 - #50031 (Clarified E0015 message.)
 - #50058 (Added build disk usage information)
 - #50081 (Update stdsimd submodule)
 - #50083 (wasm: Increase default stack size to 1MB)
 - #50104 (Disable auto-detection of libxml2 when compiling llvm.)
 - #50114 (Fix bad merge in #49991)
 - #50117 (must explicitly request file name when using with_file_name.)

Failed merges:
@bors bors merged commit b92e6c3 into rust-lang:master Apr 20, 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).
@tromey tromey mentioned this pull request Aug 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants