I'm stuck with backporting your patchset to rustc-1.49.0-src for armv7a

[stefson]

hey there, I saw the in tree rust ebuilds allow to build for amd64-musl and aarch64-musl, upstream seems to push out stage3 archives for a while now. Sadly, that is not the case for armv7a. There is only a rust-std for armv7-unknown-linux-musleabihf, that is not enough to bootstrap a full rustc compiler.

In an effort to bootstrap my way up slowly to at least rust-1.51.0 for proper firefox91-esr support, I tried to rebase your rustc-1.47.0 patchset, and I almost succeeded. Only one patch gives me a big headache, that is the 0030-libc-linkage.patch: https://github.com/smaeul/portage-overlay/blob/master/dev-lang/rust/files/0030-libc-linkage.patch#L7

this is my backport, just switching the dir name:

--- rustc-1.48.0-src/vendor/libc/src/lib.rs
+++ rustc-1.48.0-src/vendor/libc/src/lib.rs
@@ -27,6 +27,7 @@
 #![deny(missing_copy_implementations, safe_packed_borrows)]
 #![no_std]
 #![cfg_attr(feature = "rustc-dep-of-std", no_core)]
+#![cfg_attr(target_env = "musl", feature(static_nobundle))]
 #![cfg_attr(target_os = "redox", feature(static_nobundle))]
 #![cfg_attr(libc_const_extern_fn, feature(const_extern_fn))]

which fails with this error:

error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /var/tmp/portage/dev-lang/rust-1.48.0/work/rustc-1.48.0-src/vendor/libc/src/lib.rs:30:34
   |
30 | #![cfg_attr(target_env = "musl", feature(static_nobundle))]
   |                                  ^^^^^^^^^^^^^^^^^^^^^^^^

only solution for this problem I was able to find is to use a nightly compiler, that is not an option in this case it seems to me. All other patches were rather easy, but this one I don't get it what to do to fix it. Can you please help me to find a solution?

[smaeul]

I bumped rust to 1.48 a few months ago, but never published it because I didn't have opportunity to test it well. My solution was to use the "secret" nightly escape hatch: exporting RUSTC_BOOTSTRAP=1 turns any stable compiler into a nightly compiler. This is already used for much of the rustc build, because the compiler itself uses nightly features, but apparently not when building the libc crate.

See commit f99138c.

[stefson]

thank you so much for pushing the patchset, but tell me where did it end up? Its clearly not merged to the overlay, hence I pulled the commit via wget https://github.com/smaeul/portage-overlay/commit/f99138c539a8ca87dfc35b97a3125002b8ebbfe4.patch and applied it manually to the overlay file tree.

[stefson]

so, I've tested rust-1.48.0 a bit.

It compiles bootstraps and compiles fine on amd64, and armv7a. I was able to compile librsvg and cbindgen on both of them, plus spidermonkey for amd64.

so you can commit rust-1.48.0 ebuild and patchset to the overlay, if that counts as testing for you.

[stefson]

@smaeul I just saw the ppc64 stages you built, and I imagine that there must be a patchset and other fancy stuff. Do you think its possible to release them? Sadly, I never made it to a self hosting rust for armv7a :(

for aarch64-musl, all is fine with the in-tree ebuild.

[smaeul]

The patches are in the gentoo-* branches at https://github.com/smaeul/rust/branches. For now, I am just trying to get caught back up, so I did not try cross-compiling, packaging, or running the test suite. And those patches are only a direct rebase of the existing patch stack.

[stefson]

I don't really understand? I saw the stages and assumed that there is a fully working patchset, otherwise they must not exist? :-S

[stefson]

maybe this patch will work:

https://github.com/alpinelinux/aports/blob/84cf799d60562c60d1b2cb54a466c80364880aff/community/rust/link-musl-dynamically.patch

[stefson]

@smaeul which rust chost do you recommend for armv7a?

The prebuilt rust-1.48 stage actually has armv7a-unknown-linux-musleabihf , can I (should I?) just switch to armv7-unknown-linux-musleabihf for building cbindgen, librsvg, spidermonkey and firefox? Or is this the rust-std cross-libc target for glibc based systems and should be avoided?

Also, are http-parser and libssh2 dependencies still needed for musl based rust compiler?

(I have the patchset backported up to 1.55.0 on amd64, but need more time to test with really slow armv7 hardware)

[smaeul]

I don't have any specific recommendation. As long as you are adding a CHOST, and not modifying an upstream CHOST, you should not have any compatibility problems. The CHOST I used when building stage tarballs isn't really important.

Yes, http-parser and libssh2 are still needed. They are dependencies of cargo. (See lddtree /usr/bin/cargo.)

[stefson]

Ok, so its possible to switch over to armv7-gentoo-linux-musleabihf, introduced with the 0015-Add-gentoo-target-specs.patch?

based on lddtree alone it seems that the dependency on libhttp_parser.so was dropped with dev-lang/rust-1.48.0; most likely replaced by libnghttp2.so through libcurl.so

lddtree /usr/bin/cargo
cargo => /usr/bin/cargo (interpreter => /lib/ld-musl-armhf.so.1)
    libstd-21cd9210dc39c31b.so => /usr/lib/rust/1.48.0/lib/rustlib/armv7a-unknown-linux-musleabihf/lib/libstd-21cd9210dc39c31b.so
    libssh2.so.1 => /usr/lib/libssh2.so.1
    libssl.so.1.1 => /usr/lib/libssl.so.1.1
    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
    libz.so.1 => /lib/libz.so.1
    libcurl.so.4 => /usr/lib/libcurl.so.4
        libnghttp2.so.14 => /usr/lib/libnghttp2.so.14
    libgcc_s.so.1 => /usr/lib/gcc/armv7a-unknown-linux-musleabihf/9.4.0/libgcc_s.so.1
    libc.so => /usr/lib/libc.so

same with amd64 and dev-lang/rust-1.49.0

cargo => /usr/bin/cargo (interpreter => /lib/ld-musl-x86_64.so.1)
    libstd-cb72b88fcf7d12ca.so => /usr/lib/rust/1.49.0/lib/rustlib/x86_64-gentoo-linux-musl/lib/libstd-cb72b88fcf7d12ca.so
    libssh2.so.1 => /usr/lib/libssh2.so.1
    libssl.so.1.1 => /usr/lib/libssl.so.1.1
    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
    libz.so.1 => /lib/libz.so.1
    libcurl.so.4 => /usr/lib/libcurl.so.4
        libnghttp2.so.14 => /usr/lib/libnghttp2.so.14
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-gentoo-linux-musl/11.2.0/libgcc_s.so.1
    libc.so => /usr/lib/libc.so

even though I can clearly see the libssh2.so, the ebuilds from gentoo tree dropped libssh2 dep with the introduction of rust-1.47.0 ebuild

[stefson]

how confident are you in your statement, that cargo must be linked against libssh2? The more I read about it in older bugs (https://bugs.gentoo.org/749381), the more I get the impression that the ebuild actually overlinks against libssh2.so

you seem to have linked the stages statically, so they should work, but it might be a problem further down the road with subsequent uses of "system-bootstrap"

[smaeul]

I didn't mean to imply that cargo must link libssh2. In fact, I have run into the exact issue from that bug, and agree with the solution to use the bundled libssh2. I only meant that cargo currently does link libssh2.

[stefson]

/usr/bin/cargo without system-libssh2:

lddtree /usr/bin/cargo
cargo => /usr/bin/cargo (interpreter => /lib/ld-musl-x86_64.so.1)
    libstd-cb72b88fcf7d12ca.so => /usr/lib/rust/1.49.0/lib/rustlib/x86_64-gentoo-linux-musl/lib/libstd-cb72b88fcf7d12ca.so
    libssl.so.1.1 => /usr/lib/libssl.so.1.1
    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
    libz.so.1 => /lib/libz.so.1
    libcurl.so.4 => /usr/lib/libcurl.so.4
        libnghttp2.so.14 => /usr/lib/libnghttp2.so.14
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-gentoo-linux-musl/11.2.0/libgcc_s.so.1
    libc.so => /usr/lib/libc.so

[stefson]

I can confirm working firefox for armv7a:

[stefson]

Can you please commit the libssh2 removal? I have 1.50.0 queued up (:

[stefson]

I continued my porting, it was painfree up to rust-1.53.0 which allows to build firefox-96.0 and unbreaks cbindgen, and cargo-c also.

With rust-1.54.0, I'm a bit stuck because compiler/rustc_codegen_ssa/src/back/link.rs has changed a lot in: rust-lang/rust@db555e1#diff-862130c0af71054886913befc8084094485fa7d764d95f55644e033e34acd126R2167

your patch 0005-Use-static-native-libraries-when-linking-static-exec.patch took care of setting up two case, for crate_type == config::CrateType::Executable and option 1 and option 2 link statically(name), else do link dynamic(name)

to modify the new file to the old behavior doesn't seem to work, so I'm a little lost here.

I got away with dropping the patch for now, but thats not a good strategy here, is it?

[stefson]

other than that, things are just fine:

rustc -Vv
rustc 1.58.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-gentoo-linux-musl
release: 1.58.1
LLVM version: 13.0.0

[smaeul]

Did you see the branches here? https://github.com/smaeul/rust/branches

For example that patch I have in 1.58.1 as smaeul/rust@5751145.

[stefson]

Yes I did have a look at them, but for some reason it doesn't ship the libc patch and when I finally got that sorted out I must have forgotten about them 🤣

[stefson]

hey, I just saw that you forwarded the ebuilds to 1.58.1 and 1.59.0, including the patchset - seems you agree with me to drop the libc patch for 1.59.0 - you don't know why this isn't needed anymore, do you?

also, can you make use of these files? maybe its possible to repack them to a full stage consisting of rustc, std and cargo?

 3364 -rw-r--r-- 1 root root  3444532 Apr  6 07:45 cargo-1.58.1-armv7a-unknown-linux-musleabihf.tar.xz
19620 -rw-r--r-- 1 root root 20088900 Apr  6 07:45 rust-std-1.58.1-armv7a-unknown-linux-musleabihf.tar.xz
44632 -rw-r--r-- 1 root root 45700772 Apr  6 07:45 rustc-1.58.1-armv7a-unknown-linux-musleabihf.tar.xz

[smaeul]

seems you agree with me to drop the libc patch for 1.59.0 - you don't know why this isn't needed anymore, do you?

rust-lang/libc#2272 as part of rust-lang/rust#90527.

[stefson]

@smaeul I managed to continue with backporting your patchset up to rust-1.64.0, and I also managed to repack all of rustc, rust-std and cargo into one stage: rust-1.64.0-armv7a-unknown-linux-musleabihf.tar.xz It would mean the world to me if you can accept the files on your server :D

Also I did have a quick look at the 1.65.0 beta branch, and it seems there are many changes, maybe too many for me to grasp. Do you think its possible for you to have a look at my efforts, once 1.65.0 has hit the stable channels? I'll try my best to solve this myself, but I may fail badly :D

[stefson]

Issue with rust-1.65.0_beta was solved via rust-lang/rust#101942