currently, dev-lang/rust-1.39.0 ebuild does install it's rustlib into an own subfolder called ${P}, this confuses some binaries when trying to find the rust std libs: cargo bloat Error: failed to find a dir with std libraries. Expected location: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib. looking at the ebuild, this seems intentional: [install] prefix = "${EPREFIX}/usr" libdir = "$(get_libdir)/${P}" docdir = "share/doc/${P}" mandir = "share/${P}/man" why is there an additional path added to the config? can all these ${P} variables be dropped?
Created attachment 600586 [details] output from emerge --info
elevating to 'major', because several packages could suffer.
it's not major, we've been doing it for a long time. for reference: discussion with cargo-bloat author https://github.com/RazrFalcon/cargo-bloat/issues/51 original bug why it was moved: https://bugs.gentoo.org/667966 another reason is ability to co-install with rust from overlay, we had clashing files before. dumping them straight to /usr/<libdir> is not correct either, thou we could use debian's patch https://sources.debian.org/patches/rustc/1.39.0+dfsg1-4/d-add-soname.patch/ that adds soname that will shut up QA check. also there's portage bug involved https://bugs.gentoo.org/show_bug.cgi?id=694248 I'll investigate a bit, but I think the easier way will be patching bloat for now.
ok after digging it a bit I agree we should adjust paths to be clear public libs should go to /usr/$(get_libdir) and private and target libs should go to /usr/lib/rustlib/${rust_target_triple}/lib
best part is that it opens up system-bootstrap for rust. previously my attempts to bootstrap using system-installed rust were failing due to bootstrap unable to find std libs, now I know why lol.
I'm lacking the deeper understanding of the issue, so propapably can't help that much with fixing it, but I'm willing to test any proposed fix.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0449fb463341e064a926929e1c6d1c22b963891 commit a0449fb463341e064a926929e1c6d1c22b963891 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2019-12-29 10:17:49 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2019-12-30 09:58:30 +0000 dev-lang/rust: revbump 1.40.0 with fixes add parallel-compiler useflag, to use pass RUSTFLAGS=" -Zthreads=<num>" add debian soname patch add system-bootstrap install rustlib into /usr/lib unconditionally drop multilib hacks various minor fixes add myself to metadata.xml explicitly Bug: https://bugs.gentoo.org/694248 Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/703470 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/files/1.40.0-add-soname.patch | 36 +++ dev-lang/rust/metadata.xml | 6 + dev-lang/rust/rust-1.40.0-r1.ebuild | 340 ++++++++++++++++++++++++++++ 3 files changed, 382 insertions(+)
thank you so much for the fast fix, the initial problem is solved now. But mind you, that on an amd64 machine, most libs are installed into /usr/lib/rustlib, while few libs are installed into /usr/lib64/ is this what you intended?
there's a typo, should be rustlib instead of rurstlib: https://github.com/gentoo/gentoo/blob/master/dev-lang/rust/rust-1.40.0-r1.ebuild#L101
there might be another typo somewhere in the new virtual: user # emerge pv =virtual/rust-1.40.0 --nodeps [ebuild N ] sys-apps/pv-1.6.6 USE="nls -debug" [ebuild U ~] virtual/rust-1.40.0 [1.39.0] ABI_X86="(64%*) -32% (-x32)" The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by =virtual/rust-1.40.0 (argument) =virtual/rust-1.40.0 ~amd64 this likely indicates that some variable of PV might not be handled properly?
Thanks for feedback! Second one is a type on you commandline, I also always install pv =) it should be -pv That’s how I discovered that wonderful utility, not kidding, it’s great.
And of course I made a typo in a word typo.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce2a266d1db4ad5e2bde4a729772a7065213c50b commit ce2a266d1db4ad5e2bde4a729772a7065213c50b Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2019-12-30 19:11:19 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2019-12-30 19:19:54 +0000 dev-lang/rust: fix small typo in 1.40-r1 ebuild Bug: https://bugs.gentoo.org/703744 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/rust-1.40.0-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to tt_1 from comment #8) > > But mind you, that on an amd64 machine, most libs are installed into > /usr/lib/rustlib, while few libs are installed into /usr/lib64/ > > is this what you intended? yes' it's intended and ok. those a public libs if stuff wants to link to them and rustc itself uses them. it will not find it's libs in /usr/lib due to ld search path. rustc => /usr/bin/rustc (interpreter => /lib64/ld64.so.2) librustc_driver-392e7f17f33a51e3.so => /usr/lib64/librustc_driver-392e7f17f33a51e3.so libtest-a215d318b8c82ccb.so => /usr/lib64/libtest-a215d318b8c82ccb.so libdl.so.2 => /lib64/libdl.so.2 libpthread.so.0 => /lib64/libpthread.so.0 libgcc_s.so.1 => /usr/lib/gcc/powerpc64le-unknown-linux-gnu/9.2.0/libgcc_s.so.1 ld64.so.2 => /lib64/ld64.so.2 libm.so.6 => /lib64/libm.so.6 libstd-75405bbdc5edd537.so => /usr/lib64/libstd-75405bbdc5edd537.so libc.so.6 => /lib64/libc.so.6 it's illegal to install 64bit libs to /usr/lib directly on a typical system, but ok to do so in a subdir on other hand.
Created attachment 601944 [details] files list from rust-1.40.0-r1 here's the file list, if it's as intended you can close the bug I guess.
yup, looks correct. thanks again for bringing this up. I'd leave bug open till all versions are switched to this layout.
there's one note in the log though: * QA Notice: The following shared libraries lack a SONAME * /usr/lib64/librustc_macros-83f7419bcdc43db4.so
that's ok, just fixed it, should not pop up anymore.
looks all shiny and fancy to me now :)
so starting with 1.43.0 we can could custom libdir again, thanks to https://github.com/rust-lang/rust/pull/69608 I'll re-visit this bug when 1.43 time comes. the only thing that may fail is bootstrap. it was failing to find libdir as well. has bootstrap been updated to take advantage of that new libdir locator? or it takes the value of libdir automatically? example of build faiure here https://bugs.gentoo.org/show_bug.cgi?id=706292
(In reply to Georgy Yakovlev from comment #20) > so starting with 1.43.0 we can could custom libdir again, thanks to > https://github.com/rust-lang/rust/pull/69608 > > I'll re-visit this bug when 1.43 time comes. > > > the only thing that may fail is bootstrap. > it was failing to find libdir as well. > has bootstrap been updated to take advantage of that new libdir locator? > or it takes the value of libdir automatically? > > example of build faiure here > https://bugs.gentoo.org/show_bug.cgi?id=706292 Bootstrap still have strange issues. With same options it build cc crate and cfg-if crate without bootstrap when building rust, but with bootstrap cfg-if fails.
Created attachment 627606 [details] GZipped logs from building without boostrap with alternative libdir
Created attachment 627634 [details] GZipped logs from building with boostrap with alternative libdir
yeah that's the failure I'm talking about. something in bootstrap of stage0 looks for /usr/lib/rustlib and not custom libdir one level deeper. maybe it's just couple of crates, but maybe more, I'll try to experiment later. still works with internal-bootstrap or rust-bin, because lib/rustlib exists.
I've opened issue on tracker: https://github.com/rust-lang/rust/issues/72661
I've found out what causes issue with bootstrapping. I got some ideas how to solve it, not sure which is better.
Created attachment 642376 [details, diff] Patch for 1.43.1 to be bootstrapped with custom libdir Could you try this patch? I have issues with some strange tests in upstream but suppose it should be enough here.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 commit 75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-07-17 00:39:23 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-07-17 06:35:02 +0000 dev-lang/rust: bump to 1.45.0 move a lot of deps to BDEPEND Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/683420 Bug: https://bugs.gentoo.org/731764 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/Manifest | 15 ++ dev-lang/rust/rust-1.45.0.ebuild | 503 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 518 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4e6ca7891bdea48a8214f8ca2a675ce00c65604 commit d4e6ca7891bdea48a8214f8ca2a675ce00c65604 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-08-03 20:08:15 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-08-03 20:11:39 +0000 dev-lang/rust: bump to 1.45.2 Install rustlib to versioned subdirectory in /usr/lib* again Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/683420 Package-Manager: Portage-3.0.1, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/Manifest | 1 + dev-lang/rust/rust-1.45.2.ebuild | 521 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 522 insertions(+)
I rolled-back the changes made in this bug originally. Rust 1.45.2 installs to /usr/lib*/rust-{ver}/rustlib again like it was. bootstrap works fine now due to Oleg's patches. cargo-bloat will probably stop working again. it needt to use new rustc's interface to check for libdir (suggested in the PR)
