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