Add new target armv7-unknown-linux-uclibceabihf

[ykoehler]

Add support for armv7 uclibc to rust.

./x.py dist

was successful, testing of toolchains via rustup as well, and binary on platform ldd output was fine and ran properly.

I am unclear how to get the ./x.py test library/std working, would need assistance.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (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.

[ykoehler]

This change also required rust-lang/backtrace-rs#396

[ykoehler]

I will have to revert the library/backtrace change.

[camelid]

FYI I think we may not be accepting new targets right now.

[skrap]

@ykoehler I am working on a libc pull request related to this target. For my use case, I am building my own toolchain via buildroot. The request was made for me to add CI for some uclibc target (e.g. mipsel-unknown-linux-uclibc) but I don't know of a good source for uclibc toolchains, and it's been suggested to me that having CI build its own toolchain may slow the process too much. Do you know of a source for uclibc-based toolchains?

[ykoehler]

@skrap I believe that buildroot is a proper way to get such toolchain. Another way would be crosstools-NG, but to my knowledge buildroot is a very popular choice amount the embedded space to generate their toolchain. Otherwise vendors will provides their toolchain but we do not know from which method they selected to build theirs. As such, I think using buildroot or assuming people will use buildroot is a very acceptable decision.

[ykoehler]

Regarding this PR, we are not using the last version of uClibc, and I do understand that inside this project we probably should, as such, I may need to adjust its content related to that. For example, the change made to the submodule backtrace would need to be removed since the last version of uClibc has the proper support which I had to disable for our version.

[ykoehler]

@camelid sounds totally reasonable, is there are way to mark this PR as dependent on that other one so that this PR gets notified when the other is closed?

[camelid]

@ykoehler For one, you should add the S-blocked label and add something to the PR description like "Blocked on #NNN". In terms of being notified, you can use GitHub to subscribe to the "merged" and "closed" events. Just click on "Customize" next to the "Notifications" header in the sidebar in the PR you want to subscribe to.

[camelid]

S-blocked can be added with this command:

@rustbot label S-blocked

[Dylan-DPC-zz]

in terms of being notified, the triage team often checks for s-blocked prs if those are unblocked,

[JohnCSimon]

Ping from triage -
@ykoehler is this still blocked?

[bors]

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

[ykoehler]

@JohnCSimon my understanding from the comment from @camelid is that new target are not being accepted at this time.

[camelid]

@JohnCSimon my understanding from the comment from @camelid is that new target are not being accepted at this time.

I am not certain about that, but that's my understanding. Although I think @JohnCSimon was referring to whether this PR is still blocked on that libc PR, which I think it is.

[bors]

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

[JohnTitor]

Triage: RFC 2803 has been merged so now it shouldn't block this, right?

[skrap]

@ykoehler I'm assuming you'll want to be a maintainer of this target (per the new RFC rust-lang/rfcs#2803) . If you want an additional person, I'm happy to be added as well.

[skrap]

I can confirm that, with rust 1.53.0, this patch allows a full build of rust:

Dist rust-std-1.53.0-armv7-unknown-linux-uclibceabihf
	finished in 16.174 seconds

1.52.1 did not build due to missing pwrite64 symbol in libc when building for uclibc targets. (my fault, thx @JohnTitor for the fix!)

[Dylan-DPC-zz]

@kennytm this looks ready for review

err didnt see the conflict

@ykoehler if you can resolve the conflict we can try and push this forward

[skrap]

@ykoehler There's an additional commit I'd like to suggest for your branch, which fixes a crash when accessing std::env::args:

From 221f4b10d421dca92ffb42e079c3ad8f2ff55232 Mon Sep 17 00:00:00 2001
From: Jonah Petri <[email protected]>
Date: Tue, 3 Aug 2021 14:14:53 -0400
Subject: [PATCH] uclibc does not pass argv/argc in a glibc-compatible way

---
 library/std/src/sys/unix/args.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/library/std/src/sys/unix/args.rs b/library/std/src/sys/unix/args.rs
index 2805b2964d1..94364f9c874 100644
--- a/library/std/src/sys/unix/args.rs
+++ b/library/std/src/sys/unix/args.rs
@@ -103,14 +103,14 @@ mod imp {
         // still initialize here.
         #[cfg(any(
             miri,
-            not(all(target_os = "linux", any(target_env = "gnu", target_env = "uclibc")))
+            not(all(target_os = "linux", any(target_env = "gnu")))
         ))]
         really_init(_argc, _argv);
     }
 
     /// glibc passes argc, argv, and envp to functions in .init_array, as a non-standard extension.
     /// This allows `std::env::args` to work even in a `cdylib`, as it does on macOS and Windows.
-    #[cfg(all(target_os = "linux", any(target_env = "gnu", target_env = "uclibc")))]
+    #[cfg(all(target_os = "linux", any(target_env = "gnu")))]
     #[used]
     #[link_section = ".init_array.00099"]
     static ARGV_INIT_ARRAY: extern "C" fn(
-- 
2.32.0

[JohnCSimon]

Ping again from triage:

@ykoehler if you can resolve the conflict we can try and push this forward

[skrap]

@JohnCSimon It seems that this PR's author is not responding. I am interested in pushing this PR forward. Is that possible? If so, how should I proceed? I could file a PR with the same purpose.

[JohnCSimon]

@skrap not sure about the process, maybe contact the reviewer?

[ykoehler]

@JohnCSimon The interest for me to pursue this has dropped since our embedded toolchains doesn't have the latest version as it is required in here. From what a gather from this experience, I do not get why rust is not supporting uclibc for all platforms, since basically, it appears to be a matter of building a toolchain with buildroot and enabling the existing exception created for uclibc throughout the code. And the fact that if this PR goes through I suddenly become responsible for this triplet as per rust policy, I found it really strange, since other than compiling this and enabling the uclibc exception there was not much additional work and having the responsibility to then maintain this is outside the time/resources I have available.

I will see if I still have this build environment as to fix the conflicts, but if you want to kill this PR and take ownership (and from their policy, responsibility) then I am totally fine with that.

[skrap]

@ykoehler I'm not affiliated with the Rust project, but I have employer support to maintain this target. If you don't object, I'll submit a new PR based on this one, and I'll be happy to be the contact person for this target triple. (This will still be tier 3 at this point.)

[pgasiorowski-es]

I am also interested in compiling for armv7-unknown-linux-uclibceabihf but don't have much experience with setting up rust toolchains and the documentation is not clear on that either. I could at least help with testing this PR but after building rust from ykoehler:master and trying to cross compile a simple hello-word thing I'm experiencing several problems:

First when trying add the target:

rustup target add armv7-unknown-linux-uclibceabihf

error: toolchain 'stable-x86_64-unknown-linux-gnu' does not contain
component 'rust-std' for target 'armv7-unknown-linux-uclibceabihf'

note: not all platforms have the standard library pre-compiled:
https://doc.rust-lang.org/nightly/rustc/platform-support.html

So I updated .cargo/config to add it manually:

[build]
target = "armv7-unknown-linux-uclibceabihf"


[target.armv7-unknown-linux-uclibceabihf]
linker = "arm-linux-uclibceabihf-gcc"
ar = "arm-linux-uclibceabihf-ar"

but when running cargo build I'm getting:

   Compiling arm v0.1.0 (/home/woodzu/development/arm)
error[E0463]: can't find crate for `std`
  |
  = note: the `armv7-unknown-linux-uclibceabihf` target may not be
installed

I understand the problem is that it needs a crate / source code of uclibc but it's not clear how to supply that. Any help would be appreciated.

[ykoehler]

Jonah Petri, please go ahead and proceed.

…

On Mon, 13 Sept 2021 at 23:14, Jonah Petri ***@***.***> wrote: @ykoehler <https://github.com/ykoehler> I'm not affiliated with the Rust project, but I have employer support to maintain this target. If you don't object, I'll submit a new PR based on this one, and I'll be happy to be the contact person for this target triple. (This will still be tier 3 at this point.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#79380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU45D6PEKKXP6UOC3KAZWTUB24XRANCNFSM4UA7Y4UQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Yannick Koehler Courriel: ***@***.***

[oli-obk]

Closing in favour of #88952