Bug 835414 – dev-lang/rust: gentoo-musl-target-specs patch has wrong mapping for armv7a-musl

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description tt_1 2022-03-16 09:01:13 UTC]

hey everyone, 

I got a build error while bootstrapping dev-lang/rust for armv7a-musl, and I came to the conclusion that the gentoo patch for musl targets populates a non existing value for armv7a-musl: 

https://github.com/gentoo/gentoo/blob/master/dev-lang/rust/files/1.49.0-gentoo-musl-target-specs.patch#L84

to my understanding, the patch does take care of mapping gcc-chost to rust-chost in compiler/rustc_target/src/spec/mod.rs ; with gcc-chost on the left side and rust-chost on the right side. 

there is no musl-stage with gcc-chost of armv7-gentoo-linux-musleabihf, however there is armv7a-unknown-linux-musleabihf. so this works for me: 

diff --git a/compiler/rustc_target/src/spec/mod.rs b/compiler/rustc_target/src/spec/mod.rs
index 967424b..8ede388 100644
--- a/compiler/rustc_target/src/spec/mod.rs
+++ b/compiler/rustc_target/src/spec/mod.rs
@@ -477,7 +477,7 @@ macro_rules! supported_targets {
 
 supported_targets! {
     ("aarch64-gentoo-linux-musl", aarch64_gentoo_linux_musl),
-    ("armv7-gentoo-linux-musleabihf", armv7_gentoo_linux_musleabihf),
+    ("armv7a-unknown-linux-musleabihf", armv7_gentoo_linux_musleabihf),
     ("i686-gentoo-linux-musl", i686_gentoo_linux_musl),
     ("powerpc-gentoo-linux-musl", powerpc_gentoo_linux_musl),
     ("powerpc64-gentoo-linux-musl", powerpc64_gentoo_linux_musl),



Please take my analysis into consideration, I'm uncertain wether its correct and can be generalized for everyone else. 

I will provide the build log in a few hours, its just really slowly building.

[Comment 1 tt_1 2022-03-16 09:02:34 UTC]

Created attachment 767169 [details]
output from emerge --info

[Comment 2 tt_1 2022-04-08 06:15:13 UTC]

Created attachment 769322 [details, diff]
updated patch from smaeul

[Comment 3 Georgy Yakovlev 2022-04-28 08:17:08 UTC]

I'm pretty sure we did not want literal mapping, but match upstream one with vendor field adjusted.
I'll try to look at this soon.

[Comment 4 tt_1 2022-04-28 14:13:29 UTC]

please ignore everything I wrote in my initial posting, the attached patch from posting #2 is the one solving all my problems with this. 

smaeul wrote it, and published it via his rust fork on github as I provided in URL

[Comment 5 Georgy Yakovlev 2022-09-24 04:53:12 UTC]

we've decided to drop this patch and no longer pursue using -gentoo- vendor triplets.

all rust versions with this patch are soon to be removed.

[Comment 6 tt_1 2022-09-24 07:15:09 UTC]

so what are your plans for the musl targets? can you maybe write a news item to inform everyone what their rust target is supposed to be named?

[Comment 7 Georgy Yakovlev 2022-09-24 17:00:39 UTC]

(In reply to tt_1 from comment #6)
> so what are your plans for the musl targets? can you maybe write a news item
> to inform everyone what their rust target is supposed to be named?

-unknown-linux-musl*, default one.

We just patch musl base definition to be dynamic.
Even if you define new musl target - it’ll be dynamic unless explicitly configured to be static.

[Comment 8 tt_1 2022-09-24 17:23:09 UTC]

(In reply to Georgy Yakovlev from comment #7)
> (In reply to tt_1 from comment #6)
> > so what are your plans for the musl targets? can you maybe write a news item
> > to inform everyone what their rust target is supposed to be named?
> 
> -unknown-linux-musl*, default one.
> 
> We just patch musl base definition to be dynamic.
> Even if you define new musl target - it’ll be dynamic unless explicitly
> configured to be static.

ok, so for armv7-hardfloat+musl it is armv7a-unknown-linux-musleabihf then? Can you please confirm? 

If so I'll try to tackle it, the first attemp failed (see https://bugs.gentoo.org/872533)