musl-powered rust playground

[stefson]

@ernsteiswuerfel I pushed 1.52.1 and 1.53.0

please always make a backup with quickpkg once you went up one version successfully, and please never ever use +system-llvm, you can end up in horrible and maybe unfixable circular dependency situations.

with 1.53.0 you can compile librsvg-2.52.5, firefox-96.0 and eapi8 ebuilds such as cbindgen, it seems to be a good base for now untill I figured out what to do with patch 0005-Use-static-native-libraries-when-linking-static-exec.patch for rust-1.54.0

the in tree dev-lang/rust-1.58.1 ebuild has a dist useflag, where it seems to be possible to emerge it with a freshly packed stage2 archive: Install dist tarballs (used for bootstrapping) so maybe its possible to use that for getting fresh llvm-13 based stages nativly build

[ernsteiswuerfel]

Thanks! Updating to 1.53 worked flawlessly on ppc64. cbindgen and Firefox ESR are still buildable, did not try firefox-96.0 yet.

librsvg-2.52.5 fails however.
librsvg-2.52.5:20220323-134919.log

[stefson]

you can try this fix from alpine:
0001-fixup-system-deps-targets.patch.zip

[ernsteiswuerfel]

The patch worked librsvg-2.52.5 built fine, thanks!

[ernsteiswuerfel]

@stefson Fiddled around with the ppc build a bit. Turned out I needed only this small patch to make it build: https://github.com/void-ppc/void-packages/blob/master/srcpkgs/rust/patches/fix-ppc32.patch

It did not apply on rust-1.49.0::smaeul but this was easy to fix. Bootstrapping from 1.49.0 working fine so far with the patch. 1.50.0 done and 1.51.0 in the works. 🥳
fix-ppc32.patch.zip

[ernsteiswuerfel]

Ok, so btootstrapping up to 1.53.0 worked well with the patch on ppc32. Next I was hoping to build librsvg-2.52.5 on ppc but this failed.
librsvg-2.52.5:20220402-222802.log

Building librsvg-2.52.7 on ppc musl on the other hand succeeds.
librsvg-2.52.7:20220402-223533.log

[stefson]

I need the output of rustc -Vv and gcc -v from the powerpc-musl

[ernsteiswuerfel]

 # rustc -Vv
rustc 1.53.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: powerpc-gentoo-linux-musl
release: 1.53.0
LLVM version: 12.0.1

 # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-gentoo-linux-musl/11.2.1/lto-wrapper
Target: powerpc-gentoo-linux-musl
Configured with: /var/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/configure --host=powerpc-gentoo-linux-musl --build=powerpc-gentoo-linux-musl --prefix=/usr --bindir=/usr/powerpc-gentoo-linux-musl/gcc-bin/11.2.1 --includedir=/usr/lib/gcc/powerpc-gentoo-linux-musl/11.2.1/include --datadir=/usr/share/gcc-data/powerpc-gentoo-linux-musl/11.2.1 --mandir=/usr/share/gcc-data/powerpc-gentoo-linux-musl/11.2.1/man --infodir=/usr/share/gcc-data/powerpc-gentoo-linux-musl/11.2.1/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-gentoo-linux-musl/11.2.1/include/g++-v11 --with-python-dir=/share/gcc-data/powerpc-gentoo-linux-musl/11.2.1/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.1_p20220115 p4' --disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220115 (Gentoo 11.2.1_p20220115 p4)

[stefson]

I did some research about this and learned that powerpc simply doesn't have AtomicI64 support, neither gnu based nor musl based rustc. Some crates work around it, others don't, but custom targets such as all of our musl based ones need to intervene here manually.

Try this approach please, its the least invasive:

diff --git a/.cargo/config b/.cargo/config
index a94e912..ccf8ea3 100644
--- a/.cargo/config
+++ b/.cargo/config
@@ -9,3 +9,6 @@ replace-with = 'vendored-sources'
 
 [source.vendored-sources]
 directory = './vendor'
+
+[target.powerpc-gentoo-linux-musl]
+rustflags = ["--cfg", "crossbeam_no_atomic_64"]

its against librsvg-2.52.5, please drop into /etc/portage/patches and report back

[ernsteiswuerfel]

With this patch librsvg-2.52.5 built without problems. Thanks!

[stefson]

I stole the idea from here: crossbeam-rs/crossbeam#731 , it might happen again for cargo-c or any other ebuild that uses the crossbeam crates, and the fix would be similar.

An alternative is to export as RUSTFLAG through /etc/portage/make.conf or on a per package based env file in /etc/portage/env/

[stefson]

I pushed rust-1.54.0 for you. please report back with positive and negative feedback.

you will need the updated patch for librsvg-2.52.6: 0001-fixup-system-deps-targets.patch.gz

[stefson]

1.53.0 at work:

[ernsteiswuerfel]

I pushed rust-1.54.0 for you. please report back with positive and negative feedback.

 * Applying 0016-fix-ppc32.patch ...
patching file src/bootstrap/builder.rs
Hunk #1 FAILED at 1299.

You need to take my modified version, the original one would not apply (see my comment above).

[stefson]

I see, the merge window of the underlying change is between 1.55.0 and 1.57.0; before that it has to be backported. It was a blind shot, because I'm a bit ahead of publishing the ebuilds here and the ebuild won't let me src_prepare without a useable system-rust lol

//edit: underlying change is merged in 1.56.1

[ernsteiswuerfel]

Ok, rust-1.54.0 and librsvg-2.52.6 built fine on ppc64. 🥳 ppc coming up next...