musl-powered rust playground #1
Comments
|
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. |
|
you can try this fix from alpine: |
|
The patch worked librsvg-2.52.5 built fine, thanks! |
|
@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. 🥳 |
|
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. Building librsvg-2.52.7 on ppc musl on the other hand succeeds. |
|
I need the output of rustc -Vv and gcc -v from the powerpc-musl |
|
|
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: its against librsvg-2.52.5, please drop into /etc/portage/patches and report back |
|
With this patch librsvg-2.52.5 built without problems. Thanks! |
|
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 |
|
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 |
|
1.53.0 at work:
|
You need to take my modified version, the original one would not apply (see my comment above). |
|
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 |
|
Ok, rust-1.54.0 and librsvg-2.52.6 built fine on ppc64. 🥳 ppc coming up next... |
|
Success on ppc too with rust-1.54.0 and librsvg-2.52.6! |
|
I pushed 1.55.0 and 1.56.1, hopefully I didn't mess up the ppc32 patch again 🤣 1.56.1 is llvm13 based, with it you can emerge librsvg-2.54.0 please test and report back |
|
1.56.1 upgrade went flawless on ppc64. It did not build librsvg-2.54.0 however: librsvg-2.54.0:20220406-103703.log I'll try ppc32 next. |
|
you forgot to forward the patch, its still needed. |
|
Oops... Yes, with the patch librsvg-2.54.0 builds fine! Btw. could you add rust-1.48.0 and 1.49.0 from smaeuls overlay to yours? This way interested users could bootstrap up to 1.56.1 without the need of installing 2 overlays. Would be more convenient. |
|
honestly I'm more interested into getting the powerpc issue fixed upstream. Do you still have the failed build log available? I forgot where you mentioned it for the first time. |
|
I think you mean this thread: gentoo/musl#366 (comment) |
|
the ppc32 patch only extends the whitelist to include powerpcle-* targets; but you are not on little endian, are you? could be helpfull for me if you shared the output of cpuid with me. |
|
No, i have all my PPC machines on BE. The Talos II which I booted into the ppc32 G4 partition (to build 1.55.0 and 1.56.1 right now) shows this data: |
|
given by the information you gave me, this should be sufficent to fix your problem: which is the original patch: rust-lang/rust@283619c the patch used right now merely extends the target.triple to powerpcle, but your system should not take notice of that. I could be wrong though, don't have any hardware to test. |
|
True. I successfully built 1.56.1 on ppc with the ppc32 patch disabled. I think the versions before still need the (original) patch. The powerpcle target triple is Void Linux only AFAIK and that's where I got the patch from. They are about to create a ppc32 LE version of their distro. Don't know what's the working state of it however. ppc64 LE is rather common I guess. But ppc64 LE does not seem to need this patch? Don't have any PPC box on LE so I can't tell. librsvg-2.54.0 builds on ppc32 too, so all good. 😄 |
|
@ernsteiswuerfel I pushed 1.57.0 to the overlay, this is enough to build you nice firefox-99.0 and firefox-100.0 beta if you feel like testing them. |
|
1.58.1 at work:
|
|
hint: webrtc is horribly broken with the last update in firefox-94.0 on any arch except amd64, arm64 and x86 I believe. Simply pass additional --disable-webrtc |
|
Meanwhile I upgraded toolchain to musl-1.2.3 and binutils-2.38-r1 (+ gcc-11.2.1_p20220115 as before) on ppc64. And I am on your rust-1.58.1 now. rust-1.57 did not build with binutils-2.38-r1 (see logfile), I needed to use binutils-2.37_p1-r2. Did not build any of the new Firefox versions yet, only ESR. |
|
I was a bit occupied by other stuff but finally I opened an issue: crossbeam-rs/crossbeam#924 |
|
Crossbeam should be fixed upstream now! |
|
oh indeed, that patch seems pretty good. The problem with testing this is, you need get the fix into librsvg. Their devs will only update the crate to a fixed state if there is at least a point release available. So maybe you can ask the crossbeam devs to cut a point release with the fixes included? If they agree and the update is available, you can then go to the librsvg devs and ask for the crossbeam crates to be updated, with the fix included. And finally it will be fixed when there is a new point release of librsvg itself, with the updated crate vendored. |
|
I'd rather not annoy devs if it's not totally urgent. 😉 Last releases have been in Juni, July, September so I guess the next point release probably is not too far away. But as soon as a new release is availiable I'll point the librsvg devs to it and ask them the crates to be updated. |
|
I saw you posted a different ppc64 bug on the librsvg gitlab bugtracker? |
|
Ah yes, this was my librsvg-2.55.1 build on ppc64-musl. At the time I filed this one I was not sure this being the same bug as on ppc32 as the error message looked differently. Now closed as dupe of your crossbeam bug. Thanks for your efforts! |
|
I'm not entirely sure about that, since its a different crate (system-deps) which fails with ppc64 for you, but we shall see. The patch doesn't backport to the stable branch I'm afraid. |
|
you can try to reproduce the ppc64 error with current librsvg by doing this: git clone https://gitlab.gnome.org/GNOME/librsvg.git && cd librsvg if you did reproduce, try again with the patch applied on top of your local git checkout |
|
|
I pushed 1.62.1 for you, 1.63.0 will follow shortly the crossbeam crate version did change, please expect ppc32 build to fail and report back with the log if it does. |
|
Thanks! On ppc64 I need to go up from rust-1.59.0::smaeul to your 1.60.0 etc. first. Doing that right now. |
|
On ppc64 your rust built fine up to 1.63.0, thanks! But what patch to apply on librsvg? Looks like the updated crates are already used, but still the build fails: |
|
this is reproducer of https://gitlab.gnome.org/GNOME/librsvg/-/issues/916 which means only the crossbeam ppc32 bug is fixed, not the other in system-deps. |
So this is a seperate issue after all? Suppose we may run into this on ppc32 despite of the ppc32-crossbeam bug fixed? |
Here's the ppc32 rust-1.62.1 log. |
|
Yes, these are two seperate bugs. You should reopen https://gitlab.gnome.org/GNOME/librsvg/-/issues/916 I pushed the crossbeam patch for rust-1.62.1, and added the checksums few minutes later. Please report back if this is working four you on ppc32 |
|
Reopenend the ppc64 librsvg issue. rust-1.62.1 builds and works fine now on ppc32. At building ust-1.63.0 I got probably the same issue as before. |
|
Upstream librsvg issue #916 has been closed with following comment: I have no idea of how build environments look for a platform like that. For 'exotic platforms', you are on your own 😃 I hope you find some ideas in these: The panic you are seeing comes from this check in system-deps where it checks that get_builtin_target_by_triple() was able to find a suitable target. In turn, get_builtin_target_by_triple() is implemented here, which works by just comparing the triple strings against the ALL_BUILTINS list. You'll notice that there's no triple there with gentoo in it. crossbeam-rs/crossbeam#922 - replace the gentoo vendor in target triples with unknown. I have no idea if just replacing gentoo with unknown will work, although there is an entry for powerpc64-unknown-linux-musl, which may be what you want. What's easier for you to try? Patch something in system-deps or cfg-expr so they modify the triple string with unknown? Use a cross-compilation scheme to use an explicit powerpc64-unknown-linux-musl instead of gentoo's default? So how to proceed from here on? |
|
I've pushed rust-1.64.0 ebuild for you, are you ready to upgrade to llvm-15 toolchain? I've tested rust-1.65.0 extensivly, and may push both 1.65.0 and 1.66.0 soon if you want to. |
|
I already upgraded to llvm-15 toolchain on ppc32/ppc64 as some ppc32 llvm bugs have been sorted out upstream in 15.0.6 (or was it 15.0.5?). Working fine so far. I'll could give 1.65.0 and 1.66.0 a try next weekend or so. |
|
Alright, I will push them both today or tomorrow. If you run into any build error just ping me and I see what I can do. I'm not sure what to do about the librsvg problem, find it rather appalling they closed the upstream issue. At least they should leave it open and label it with |
|
Tried building 1.64.0 on ppc64 but got some problems. First I needed to alter 0016-fix-ppc32-crossbeam-utils.patch.tar.gz |
|
Patch is refreshed now, I forgot to fix the checksums. Does it now work for you? |
|
Yes, 1.64.0 successfully built on ppc64. Thanks! Only thing I needed to do now is to copy the ebuild do my localrepo and set EAPI=8 (or it won't start bullding). Also when starting to emerge I am getting lots of these: But it built fine anyhow. 1.65.0 next on ppc64... |
|
you can simply revert this commit for now: gentoo/gentoo@a8a9021 I may have to upgrade everything to eapi8, but I can't test the older ebuilds anymore due to the system-bootstrap process. Ideas, thoughts? |
|
I think there probably is no (easy) solution for that problem. Gentoo ditches old rust ebuilds after some time when new stable versions are available and old versions are no longer required for in-tree-ebuilds. To maintain the old ones incl. eclasses to keep them buildable just does not seem feasibly. Only hope would be that smaeul releases some newer rust version buildable from upstream static-rust-binaries again to use this as a starting point (again) until upstream gets this dynamic linking stuff sorted out needed at least for some distros. 😮💨 |
|
BTW bulding 1.64.0 and 1.65.0 on ppc64 went fine. On ppc32 I ran into troubles on ppc32: |
|
the ppc32 error is the same as before, its just that rust does sometimes vendors two versions of the same crate. I have yet failed to understand why this is, and why and when the build uses the versioned and when it uses the unversioned version. The static |
|
please try again with ppc32 |
|
1.64.0 successfully built on ppc32, thanks! Now the same |
@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.patchfor rust-1.54.0the 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 buildThe text was updated successfully, but these errors were encountered: