dev-lang/rust-bin: initial commit for armv7a #366
Conversation
this version of rust-bin has been tested with cbindgen-0.15, librsvg-2.48.x, spidermonkey-78 and firefox-esr-78 Signed-off-by: Steffen Kuhn <nielson2@yandex.com>
Signed-off-by: Steffen Kuhn <nielson2@yandex.com>
|
it doesn't compile >=cbindgen-0.17 anymore for me on armv7, so package is outdated as of now |
rust-bin-1.41.1 misscompiles >=dev-util/cbindgen-0.17.0 Signed-off-by: Steffen Kuhn <nielson2@yandex.com>
|
Steffen, what is the status of this work? Are you still working on it or is it ready to be merged to the overlay? |
|
well, I can't update it beyond 1.48.0 at this point, since smauel hasn't pushed out a stage of 1.51.0 yet. 1.44.1 should not go to the overlay, since its old llvm-9 based. what do you think is best? wait for new 1.51.0 stage, upgrade to llvm-10 based 1.46.0 or go for the llvm-11 based 1.48.0? |
new rust vers should 'just work' once this lands rust-lang/compiler-team#422 and then smaeul shouldn't need to maintain rust. |
|
I finally got a grip on how this patchset works and backported it. dev-lang/rust-1.49.0 is available at smaeul, and both 1.50.0 and 1.51.0 will be added in the next days. it seems not much progress has been made at upstream (for amd64 and arm64, in tree ebuilds work) |
I appreciate your efforts very much! Though I did not succeed in building your 1.49.0 on ppc. If you like, check out the build.log: I'll certainly try your next releases on ::smaeul! |
|
please provide emerge --info and emerge -pv =rust-1.49.0 |
and |
|
I did my testing of the backported patches in an amd64 chroot, there were no problems whatsoever - I'm actually sitting on the backported patchset up to =rust-1.55.0 (: You could try to switch the system-llvm flag off, and maybe the system-bootstrap flag on. |
Looks like I get the same error with -system-llvm +system-bootstrap. |
|
@ernsteiswuerfel head over to smaeul, I've got 1.50.0 ready in a pullrequest |
I was not able to merge your PR in my local smaeul repository (managed by eselect repository) but I cloned your rust-1.50 in my localrepo. Emerging 1.50 did not succeed: |
|
There are no stages available, you need to bootstrap all the way through with system-bootstrap. I remember that you failed to emerge 1.49.0, so maybe go back to 1.48.0 as a base and start to bootstrap this way? |
|
I modified the ebuild to make bootstrapping with 1.48 possible via But I didn't succeed, this version seems to be to old for 1.50 already. |
|
thats not going to work, you always need the prior main version of rust to bootstrap. rust ist a self hosting compiler, this means you can't use gcc or clang to compile it. that machine is rather fast, try to go back to rust-1.48.0 (or rust-1.47.0 if you have to), and system-bootstrap your way up from there. this seems to be your only choice to me. |
Ok, I see. Bootstrapping 1.49 on ppc32 didn't work either... Last version which builds here is 1.48. I'llt try next on ppc64 and see how that turns out. Nevertheless, thanks for you work on it anyway! 1.49 on my x86 Pentium 4 box works well.
My Talos II got 2 x 4-core POWER9 so thats 8 cores w. 32 threads. Good for distcc'ing my slower boxes or building stuff in a chroot. 😃 |
|
@stefson Meanwhile I built your 1.50.0 on ppc64 which worked perfectly well, bootstrapping the way from 1.48 up. 🌞 So only ppc(32) got a problem here. |
|
Thats really unfortunate, you can try to reach out to the musl mailing list and explain your ppc32 problem to ask for suggestions. I was having a similar problem with rust-1.41.0 before time64 was added with musl-1.2.0, so maybe some ppc32 implementation is not correct or complete. In the meantime, feel free to try the rust-1.51.0 ebuild: rust-1.51.0.tar.gz I'd be happy to hear from you if you've managed to build a firefox-91esr with that, given that this is an interesting package for you. |
|
@stefson clang build of firefox-91.7.1 failed but the gcc build succeeded. Thanks! rust-1.52.0 would be great too as you need it for current librsvg to build. Also had to lower rust requirements in cargo.eclass to make cbindgen build. |
|
unfortunatley thats not true, you need at least rust-1.54.0 to compile the now stable librsvg-1.52.6. I just spend half a day debugging this lol this one liner gets pulled in through the vendored sources: EmbarkStudios/cfg-expr@3fffc47#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R1 please add the failed build.log from the clang build so I can take a look at it. |
|
Failed clang firefox-91.7.1 build. Big Endian patches are from: https://github.com/void-ppc/void-packages/tree/master/srcpkgs/firefox/patches |
|
I've seen a similar compile error long time ago with an x86 build, it seems alpine has hit it as well. They decided to rip out the entire section: I'd say give it a try, what do you think? |
|
Turned out i needed following patch for the firefox clang build: https://github.com/void-ppc/void-packages/blob/master/srcpkgs/firefox/patches/fix-i686-ppc-musl.patch Seems to be a less invasive version of your patch posted. |
|
I think it literally means the same, as you end up at anyway, which disables the moz_stackwalk stuff. In alpine for all cases, in void-ppc for all cases except GLIBC. |
|
Btw. firefox-91.7.0 fails to build on musl x86 for another reason. |
|
this is an old bug that should have been fixed a long time ago, you may want to look at you can also try to pass EXTRA_ECONF="--disable-cranelift" via env file in /etc/portage/env/www-client/ |
Interesting, librsvg-2.52.7.ebuild only requires >=virtual/rust-1.52. |
|
the 2.52.x-librsvg ebuilds were added just a few weeks ago, no one questioned the minimal rust of 1.52 as everyone had already upgraded to a llvm-13 based rust. In short: librsvg-2.52.5 makes use of a function called librsvg-2.54.0 needs a rust compiler with I will push all the ebuilds I have ready to my own ebuild in the evening, smauel seems to need longer to review my pullrequest, or maybe he doesn't feel comfortable with depending on system-bootstrap all the way. I will tag you when its done. |
this version of rust-bin has been tested with cbindgen-0.15, librsvg-2.48.x, spidermonkey-78 and firefox-esr-78
only problem I found is that firefox needs LD_LIBRARY_PATH pointing to it's own libs, that's due to lazy binding problems during linking: https://bugs.gentoo.org/531846#c36
if CI comes back without issues, then this is good to go