Created attachment 911789 [details, diff] diff rust-bin-1.81.0-{r100,r101}.ebuild dev-lang/rust requires previous minor release of the rust toolchain since the recent transition to slotted versions. And for the first bootstrap, we have to use rust-bin. But rust-bin depends on gcc, so pure-llvm systems cannot upgrade rust anymore. This is a huge regression. I've wrote a patch for rust-bin to remove gcc dependency: rust-bin-remove-gcc-dep.patch That is what non-slotted ebuilds do in esetup_unwind_hack, and I confirmed that it also works for rust-bin on amd64 and aarch64. If this hack is acceptable, I would make a PR. But it may not be a good idea to install such a hack on the whole system. I need the maintainer's comments.
Please always give unified diffs (`diff -u`) but also the truncated headers make it kind of hard to read. `git am`-able patches generated by `git format-patch` are even better. Anyway, the patch as a concept is fine, but: a) needs commentary (even better with a commit message too); b) hardcoding /usr/lib isn't right; need a proper way of finding the path.
(In reply to Sam James from comment #1) > Please always give unified diffs (`diff -u`) but also the truncated headers > make it kind of hard to read. `git am`-able patches generated by `git > format-patch` are even better. Thanks for the advice! I will do so next time. > Anyway, the patch as a concept is fine, but: > a) needs commentary (even better with a commit message too); Sure, I'll write comments when creating a commit. > b) hardcoding /usr/lib isn't right; need a proper way of finding the path. Is `dosym libunwind.so ${EPREFIX}/usr/$(get_libdir)/libgcc_s.so` sufficient?
Wonder if `gcc -print-file-name=libgcc_s.so` would be better, but wait, now I've confused myself. (I worry I misread the diff in bed.) Can we use patchelf instead here? Or make the symlink somewhere else (+ patchelf it) where nothing else is going to find it?
Or maybe I'm misunderstanding a bit. The hack in dev-lang/rust was only in the work directory and didn't apply to the live filesystem. But dosym is for the image. But the issue we're hitting here is that we need dev-lang/rust-bin to work for real when using it in dev-lang/rust, as we're no longer stuffing it in dev-lang/rust. So, two options: 1) Add a hack in dev-lang/rust when using rust-bin, but this will leave rust-bin broken otherwise (this is a bad option); 2) Something like I suggested in https://bugs.gentoo.org/944835#c3.
Created attachment 911921 [details, diff] 0001-dev-lang-rust-bin-support-llvm-systems.patch patchelf works. Please take look at this.
That looks good to me! One small issue is 'eend $?' won't work as intended there because of the pipeline, we need to use assert or something instead (not sure assert is actually supposed to interact with eend; there's some discussion ongoing about replacing assert because of this kind of issue).
Thanks! I'm going to replace `eend $?` with `eend ${PIPESTATUS[0]}`. And I think this fix should be applied to line 147 too.
Agree that dev-lang/rust-bin should be fixed/patched, however there is a parallel effort to enable bootstrapping dev-lang/rust from source via mrustc (and filling in gaps in the bootstrap chain). Added to see-also. Since the 'get rust 1.54.0 building' step is ready to go it may be time to investigate mrustc.
*** Bug 945157 has been marked as a duplicate of this bug. ***
Please make a PR with that updated patch when ready -- thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a2e3e056ba70d19df59f2a22a44e3a53abe933e commit 0a2e3e056ba70d19df59f2a22a44e3a53abe933e Author: mojyack <mojyack@gmail.com> AuthorDate: 2024-11-28 01:59:18 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-12-09 04:49:42 +0000 dev-lang/rust-bin: remove hard gcc dependency Instead of depending to gcc, patch binaries to use libunwind.so when `llvm-libunwind` USE flag is enabled. Signed-off-by: mojyack <mojyack@gmail.com> Closes: https://bugs.gentoo.org/944835 Closes: https://github.com/gentoo/gentoo/pull/39495 Signed-off-by: Matt Jolly <kangie@gentoo.org> dev-lang/rust-bin/rust-bin-1.71.1-r101.ebuild | 245 ++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.74.1-r101.ebuild | 255 +++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.75.0-r101.ebuild | 255 +++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.77.1-r101.ebuild | 257 +++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.79.0-r101.ebuild | 260 +++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.80.1-r101.ebuild | 264 ++++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.81.0-r101.ebuild | 262 +++++++++++++++++++++++++ dev-lang/rust-bin/rust-bin-1.82.0-r101.ebuild | 264 ++++++++++++++++++++++++++ 8 files changed, 2062 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=053fb81af3f45277e1869d993c240f38d0346a71 commit 053fb81af3f45277e1869d993c240f38d0346a71 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-15 06:59:42 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-15 07:01:52 +0000 Revert "dev-lang/rust-bin: remove hard gcc dependency" This reverts commit 0a2e3e056ba70d19df59f2a22a44e3a53abe933e. This (clearly) doesn't work if symbols from libgcc_s are relied upon, like __popcountdi2. Needing sys-devel/gcc for now for rust-bin is better than having it entirely broken. Discussions on a broader fix are in progress on the bug. Bug: https://bugs.gentoo.org/944835 Bug: https://bugs.gentoo.org/946321 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/rust-bin/rust-bin-1.71.1-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.74.1-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.75.0-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.77.1-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.79.0-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.80.1-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.81.0-r101.ebuild | 15 ++------------- dev-lang/rust-bin/rust-bin-1.82.0-r101.ebuild | 15 ++------------- 8 files changed, 16 insertions(+), 104 deletions(-)
