Created attachment 657444 [details] build.log dev-lang/rust-bin-1.45.2 error: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/q/gentoo/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8-abi_x86_32.x86/target/release/deps/libproc_macro_hack-06b9136d164e1874.so)
Created attachment 657446 [details] emerge --info
Created attachment 657448 [details] dev-lang/rust build.log
after some chat on IRC we figured it looks like rust/build system somehow mixes both host (old) glibc and prefix (new) one, hence the symbol which is absent on host.
q@q-Standard-PC-Q35-ICH9-2009:~/gentoo$ ll usr/bin/rustc lrwxrwxrwx 1 q q 39 Aug 30 00:02 usr/bin/rustc -> /home/q/gentoo/usr/bin/rustc-bin-1.45.2* q@q-Standard-PC-Q35-ICH9-2009:~/gentoo$ lddtree usr/bin/rustc rustc => usr/bin/rustc (interpreter => /lib/ld-linux.so.2) librustc_driver-a070d390354c7163.so => not found libstd-c9cb5b135341e89b.so => not found librt.so.1 => /lib/i386-linux-gnu/librt.so.1 libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 ld-linux.so.2 => /lib/ld-linux.so.2
For comparison: q@q-Standard-PC-Q35-ICH9-2009:~/gentoo$ lddtree bin/bash bash => bin/bash (interpreter => /home/q/gentoo/lib/ld-linux.so.2) libreadline.so.8 => /home/q/gentoo/usr/lib/libreadline.so.8 libtinfow.so.6 => /home/q/gentoo/usr/lib/libtinfow.so.6 libtinfo.so.6 => /home/q/gentoo/usr/lib/libtinfo.so.6 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 ld-linux.so.2 => /home/q/gentoo/lib/ld-linux.so.2 Also, ldd and lddtree show different paths: q@q-Standard-PC-Q35-ICH9-2009:~/gentoo$ ldd bin/bash linux-gate.so.1 (0xb7f3c000) libreadline.so.8 => /home/q/gentoo/usr/lib/libreadline.so.8 (0xb7dff000) libtinfo.so.6 => /home/q/gentoo/usr/lib/libtinfo.so.6 (0xb7dcb000) libc.so.6 => /home/q/gentoo/lib/libc.so.6 (0xb7bea000) libtinfow.so.6 => /home/q/gentoo/usr/lib/libtinfow.so.6 (0xb7bb6000) /home/q/gentoo/lib/ld-linux.so.2 (0xb7f3d000 q@q-Standard-PC-Q35-ICH9-2009:~/gentoo$ ldd usr/bin/rustc linux-gate.so.1 (0xb7f66000) librustc_driver-a070d390354c7163.so => not found libstd-c9cb5b135341e89b.so => not found librt.so.1 => /home/q/gentoo/lib/librt.so.1 (0xb7ef6000) libdl.so.2 => /home/q/gentoo/lib/libdl.so.2 (0xb7ef0000) libpthread.so.0 => /home/q/gentoo/lib/libpthread.so.0 (0xb7ed0000) libc.so.6 => /home/q/gentoo/lib/libc.so.6 (0xb7cef000) /lib/ld-linux.so.2 => /home/q/gentoo/lib/ld-linux.so.2 (0xb7f67000)
I have reproduced this bug.
(In reply to Benda Xu from comment #6) > I have reproduced this bug. rust version? 1.47.0 (for bin and non-bin) changed a bit lib installation location, so maybe you can give it a test.
(In reply to Georgy Yakovlev from comment #7) > (In reply to Benda Xu from comment #6) > > I have reproduced this bug. > > rust version? > 1.47.0 (for bin and non-bin) changed a bit lib installation location, so > maybe you can give it a test. It was rust-bin-1.47.0. It was likely to be caused by the location of the dynamic-linker. After I ran `patchelf --set-interpreter ${EPREFIX}/lib64/ld-linux-x86-64.so.2 $(which rustc)`, the linking automatically searched inside EPREFIX and let librsvg build. It seems that rustc queries itself for the dynamic-linker, and then use that location for the ELF executables generated by it. But I am not familiar with the source code of rustc and have not verified this guess. Does it ring a bell to you?
yes, absolutely makes sense. I'll gladly accept a patch for rust-bin, which adds a dependency on patchelf and sets proper loader path, gated by prefix-specific useflag. this will allow it to work. unfortunately I don't have time to work on it myself. rust ships couple .so files and several binaries, depending on useflags. better check all of them have correct one set. with this approach we will have to force system-bootstrap for rust on prefix. it's going to be default soon, so not a big deal.
