Add ARM MUSL targets #33189

timonvo · 2016-04-25T03:39:33Z

The targets are:

arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armv7-unknown-linux-musleabihf

These mirror the existing gnueabi targets.

All of these targets produce fully static binaries, similar to the
x86 MUSL targets.

For now these targets can only be used with --rustbuild builds, as
rust-lang/compiler-rt#22 only made the
necessary compiler-rt changes in the CMake configs, not the plain
GNU Make configs.

I've tested these targets GCC 5.3.0 compiled again musl-1.1.12
(downloaded from http://musl.codu.org/). An example ./configure
invocation is:

./configure \
    --enable-rustbuild
    --target=arm-unknown-linux-musleabi \
    --musl-root="$MUSL_ROOT"

where MUSL_ROOT points to the arm-linux-musleabi prefix.
Usually that path will be of the form
/foobar/arm-linux-musleabi/arm-linux-musleabi.

Usually the cross-compile toolchain will live under
/foobar/arm-linux-musleabi/bin. That path should either by added
to your PATH variable, or you should add a section to your
config.toml as follows:

[target.arm-unknown-linux-musleabi]
cc = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-gcc"
cxx = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-g++"

As a prerequisite you'll also have to put a cross-compiled static
libunwind.a library in $MUSL_ROOT/lib. This is similar to how
the x86_64 MUSL targets are built.

r? @alexcrichton

rust-highfive · 2016-04-25T03:39:47Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

alexcrichton · 2016-04-25T04:22:47Z

src/bootstrap/build/compile.rs

@@ -83,7 +83,7 @@ pub fn std_link(build: &Build,
    add_to_sysroot(&out_dir, &libdir);

    if target.contains("musl") &&
-       (target.contains("x86_64") || target.contains("i686")) {
+       (target.contains("x86_64") || target.contains("i686") || target.contains("arm")) {


Hm perhaps this condition could be reversed to say if target.contains("musl") && !target.contains("mips") ?

alexcrichton · 2016-04-25T04:30:49Z

Thanks for the PR @timonvo, and nice!

Also cc @rust-lang/tools, curious on thoughts of the idea on using target_env = "musleabi" and "musleabihf". On one hand it's unfortunate how musl-specific code now needs three different target_env arguments instead of one, although it's consistent with how we treat the target "triple" parsing. It's also consistent with the behavior of how we treat the glibc targets (e.g. gnueabi and gnueabihf), although I highly doubt anyone's relying on that distinction.

I don't quite know what the best way to expose this would be. We could perhaps add a target_libc or also perhaps repurpose target_env, but curious what others think

timonvo · 2016-04-27T04:04:09Z

Hi Alex,

I think I've addressed all your comments. Is there anything else you'd like to see before this can land? I was thinking I'd squash the last two commits into the fe4e327 commit once you give the OK that is can be submitted.

Regarding the target_env issue, as I mentioned in an earlier PR I think this is something that should maybe be resolved, but I don't think this is the right place for it now. As for what my preferred fix is: I think a new target_libc field may be the easiest fix. I think it would also be the most clear way of handling the problem, as for any #cfg based on that value it'd become immediately clear why the conditional is there.

alexcrichton · 2016-04-27T17:03:18Z

Hm yeah I was thinking on waiting for a resolution of musleabi vs just musl, but I think you're right that it's probably best to duke out elsewhere. If you wanna do some squashes I'll r+. Thanks @timonvo!

This is to pull in changes to support ARM MUSL targets. This change also commits a couple of other cargo-generated changes to other dependencies in the various Cargo.toml files.

The targets are: - `arm-unknown-linux-musleabi` - `arm-unknown-linux-musleabihf` - `armv7-unknown-linux-musleabihf` These mirror the existing `gnueabi` targets. All of these targets produce fully static binaries, similar to the x86 MUSL targets. For now these targets can only be used with `--rustbuild` builds, as rust-lang/compiler-rt#22 only made the necessary compiler-rt changes in the CMake configs, not the plain GNU Make configs. I've tested these targets GCC 5.3.0 compiled again musl-1.1.12 (downloaded from http://musl.codu.org/). An example `./configure` invocation is: ``` ./configure \ --enable-rustbuild --target=arm-unknown-linux-musleabi \ --musl-root="$MUSL_ROOT" ``` where `MUSL_ROOT` points to the `arm-linux-musleabi` prefix. Usually that path will be of the form `/foobar/arm-linux-musleabi/arm-linux-musleabi`. Usually the cross-compile toolchain will live under `/foobar/arm-linux-musleabi/bin`. That path should either by added to your `PATH` variable, or you should add a section to your `config.toml` as follows: ``` [target.arm-unknown-linux-musleabi] cc = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-gcc" cxx = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-g++" ``` As a prerequisite you'll also have to put a cross-compiled static `libunwind.a` library in `$MUSL_ROOT/lib`. This is similar to [how the x86_64 MUSL targets are built] (https://doc.rust-lang.org/book/advanced-linking.html).

timonvo · 2016-04-28T01:03:44Z

Just did the squash of the last two commits.

alexcrichton · 2016-04-28T16:42:24Z

src/librustc_back/target/arm_unknown_linux_musleabi.rs

+        // It's important we use "gnueabi" and not "musleabi" here. LLVM uses it
+        // to determine the calling convention and float ABI, and it doesn't
+        // support the "musleabi" value.
+        llvm_target: "arm-unknown-linux-gnueabi".to_string(),


Is it intentional to pass "gneuabi" to LLVM instead of "musleabi"?

Yes it is. I believe the comment above explains why :)

Wow I can totally read

alexcrichton · 2016-04-28T16:43:04Z

Just one minor nit but otherwise r=me

alexcrichton · 2016-04-28T16:56:08Z

@bors: r+ 483d805

bors · 2016-04-28T17:11:45Z

⌛ Testing commit 483d805 with merge 9147703...

bors · 2016-04-28T17:17:43Z

💔 Test failed - auto-win-msvc-64-opt-rustbuild

alexcrichton · 2016-05-04T17:16:34Z

@timonvo in #33244 we decided that the targets should just use musl as the target_env instead of "musleabi" and "musleabihf", could you make that change as well?

timonvo · 2016-05-05T03:16:58Z

Sure, I'll try to make that change. I'm not sure when I'll have time in next week or two, so this may be on hold for a while.

@alexcrichton

rustc_back: use a common musl base extracted from #33327. cc #33189. r? @alexcrichton

@alexcrichton

rustc_back: use a common musl base extracted from #33327. cc #33189. r? @alexcrichton

bors · 2016-05-07T17:17:03Z

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

alexcrichton · 2016-06-28T20:44:01Z

Closing due to inactivity, but feel free to resubmit with a rebase!

japaric · 2016-07-26T20:55:26Z

@timonvo If you don't mind, I'm going to try to rebase this.

@alexcrichton

Add ARM MUSL targets Rebase of rust-lang#33189. I tested this by producing a std for `arm-unknown-linux-musleabi` then I cross compiled Hello world to said target. Checked that the produced binary was statically linked and verified that the binary worked under QEMU. This depends on rust-lang/libc#341. I'll have to update this PR after that libc PR is merged. I'm also working on generating ARM musl cross toolchain via crosstool-ng. Once I verified those work, I'll send a PR to rust-buildbot. r? @alexcrichton cc @timonvo

@alexcrichton

Add ARM MUSL targets Rebase of #33189. I tested this by producing a std for `arm-unknown-linux-musleabi` then I cross compiled Hello world to said target. Checked that the produced binary was statically linked and verified that the binary worked under QEMU. This depends on rust-lang/libc#341. I'll have to update this PR after that libc PR is merged. I'm also working on generating ARM musl cross toolchain via crosstool-ng. Once I verified those work, I'll send a PR to rust-buildbot. r? @alexcrichton cc @timonvo

rust-highfive assigned alexcrichton Apr 25, 2016

alexcrichton reviewed Apr 25, 2016
View reviewed changes

alexcrichton added the T-tools label Apr 25, 2016

MagaTailor mentioned this pull request Apr 25, 2016

ARM build openethereum/parity-ethereum#266

Closed

alexcrichton mentioned this pull request Apr 27, 2016

Considering add a #[cfg] option for musl/glibc split #33244

Closed

MagaTailor mentioned this pull request Apr 27, 2016

100% static binary openethereum/parity-ethereum#999

Closed

timonvo force-pushed the armmusleabi branch from 00faa0f to d750c50 Compare April 28, 2016 00:51

timonvo added 3 commits April 27, 2016 18:02

Pull in liblibc & compiler-rt changes for ARM MUSL support.

b8d3b46

Update gcc crate dependency to 0.3.27.

51153db

This is to pull in changes to support ARM MUSL targets. This change also commits a couple of other cargo-generated changes to other dependencies in the various Cargo.toml files.

timonvo force-pushed the armmusleabi branch from d750c50 to 483d805 Compare April 28, 2016 01:02

alexcrichton reviewed Apr 28, 2016
View reviewed changes

japaric mentioned this pull request May 1, 2016

static arm musl japaric/rust-cross#21

Closed

alexcrichton mentioned this pull request May 2, 2016

rustc_trans: implement lld compatibility #33327

Closed

tamird mentioned this pull request May 2, 2016

rustc_back: use a common musl base #33359

Merged

bors added a commit that referenced this pull request May 7, 2016

Auto merge of #33359 - tamird:consolidate-musl, r=alexcrichton

fe617c5

rustc_back: use a common musl base extracted from #33327. cc #33189. r? @alexcrichton

bors added a commit that referenced this pull request May 7, 2016

Auto merge of #33359 - tamird:consolidate-musl, r=alexcrichton

936b32a

rustc_back: use a common musl base extracted from #33327. cc #33189. r? @alexcrichton

alexcrichton closed this Jun 28, 2016

japaric mentioned this pull request Jul 27, 2016

Add ARM MUSL targets #35060

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ARM MUSL targets #33189

Add ARM MUSL targets #33189

timonvo commented Apr 25, 2016

rust-highfive commented Apr 25, 2016

alexcrichton Apr 25, 2016

timonvo Apr 25, 2016

alexcrichton commented Apr 25, 2016

timonvo commented Apr 27, 2016

alexcrichton commented Apr 27, 2016

timonvo commented Apr 28, 2016

alexcrichton Apr 28, 2016

timonvo Apr 28, 2016

alexcrichton Apr 28, 2016

alexcrichton commented Apr 28, 2016

alexcrichton commented Apr 28, 2016

bors commented Apr 28, 2016

bors commented Apr 28, 2016

alexcrichton commented May 4, 2016

timonvo commented May 5, 2016

bors commented May 7, 2016

alexcrichton commented Jun 28, 2016

japaric commented Jul 26, 2016

Add ARM MUSL targets #33189

Add ARM MUSL targets #33189

Conversation

timonvo commented Apr 25, 2016

rust-highfive commented Apr 25, 2016

alexcrichton Apr 25, 2016

Choose a reason for hiding this comment

timonvo Apr 25, 2016

Choose a reason for hiding this comment

alexcrichton commented Apr 25, 2016

timonvo commented Apr 27, 2016

alexcrichton commented Apr 27, 2016

timonvo commented Apr 28, 2016

alexcrichton Apr 28, 2016

Choose a reason for hiding this comment

timonvo Apr 28, 2016

Choose a reason for hiding this comment

alexcrichton Apr 28, 2016

Choose a reason for hiding this comment

alexcrichton commented Apr 28, 2016

alexcrichton commented Apr 28, 2016

bors commented Apr 28, 2016

bors commented Apr 28, 2016

alexcrichton commented May 4, 2016

timonvo commented May 5, 2016

bors commented May 7, 2016

alexcrichton commented Jun 28, 2016

japaric commented Jul 26, 2016