Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 739574 - gnome-base/librsvg-2.48.8 fails to build in prefix (rust)
Summary: gnome-base/librsvg-2.48.8 fails to build in prefix (rust)
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Rust Project
URL:
Whiteboard:
Keywords: PullRequest
Depends on: 695318
Blocks:
  Show dependency tree
 
Reported: 2020-08-29 23:15 UTC by Alexey
Modified: 2021-03-07 16:36 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,175.50 KB, text/x-log)
2020-08-29 23:15 UTC, Alexey
Details
emerge --info (emerge-info.txt,15.19 KB, text/plain)
2020-08-29 23:16 UTC, Alexey
Details
dev-lang/rust build.log (build.log,53.39 KB, text/x-log)
2020-08-29 23:36 UTC, Alexey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey 2020-08-29 23:15:59 UTC
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)
Comment 1 Alexey 2020-08-29 23:16:16 UTC
Created attachment 657446 [details]
emerge --info
Comment 2 Alexey 2020-08-29 23:36:50 UTC
Created attachment 657448 [details]
dev-lang/rust build.log
Comment 3 Georgy Yakovlev gentoo-dev 2020-08-30 00:07:38 UTC
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.
Comment 4 Alexey 2020-08-30 00:13:21 UTC
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
Comment 5 Alexey 2020-08-30 00:17:13 UTC
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)
Comment 6 Benda Xu gentoo-dev 2020-10-19 12:16:37 UTC
I have reproduced this bug.
Comment 7 Georgy Yakovlev gentoo-dev 2020-10-19 15:34:13 UTC
(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.
Comment 8 Benda Xu gentoo-dev 2020-10-26 04:42:19 UTC
(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?
Comment 9 Georgy Yakovlev gentoo-dev 2020-10-26 05:05:21 UTC
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.