Summary: | sys-libs/glibc-2.32-r3 fails: .../bin/ld: /lib/librt.so.1: undefined reference to `__clock_settime@GLIBC_PRIVATE' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Albert Zeyer <albzey> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | bircoph, sam, shinji |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sourceware.org/bugzilla/show_bug.cgi?id=27132 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
environment #2 - gd with old glibc #3 - glibc with old gd and USE=gd #4 - glibc with old gd and USE=-gd #5 - gd with new glibc #6 - glibc with new gd and USE=gd |
Description
Albert Zeyer
2020-12-30 21:39:56 UTC
Created attachment 680329 [details]
environment
Maybe this is somehow related? https://github.com/NixOS/nixpkgs/issues/84043 Filed bug upstream. Yes, this looks like it's trying to link to the installed librt.so instead of the just built one. The error does not come from this command (the joys of parallel build), but from one a few lines up in the build log (linking memusagestat): i686-pc-linux-gnu-gcc -march=athlon -pipe -O2 -Wl,-O1 -Wl,--as-needed -Wl,-rpath-link=/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl:/var/tmp/portage/sys-libs/gl ibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/math:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/elf:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i 686-pc-linux-gnu-nptl/dlfcn:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/nss:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/nis:/ var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/rt:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/resolv:/var/tmp/portage/sys-libs/gl ibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/mathvec:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/support:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/buil d-x86-i686-pc-linux-gnu-nptl/crypt:/var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/nptl -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.3 2-r3/work/build-x86-i686-pc-linux-gnu-nptl/malloc/memusagestat -Wl,-O1 -Wl,--as-needed -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu- nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/csu/crti.o `i686-pc-linux-gnu-gcc -march=athlon -pipe -O2 -Wl,-O1 -Wl,--as-needed --print-file-n ame=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/malloc/memusagestat.o -lgd -lpng -lz -lm -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-z,now /var/t mp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/libc.so.6 /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/libc_nonshared.a -Wl,--as-needed /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/elf/ld.so -Wl,--no-as-needed -lgcc `i686-pc-linux-gnu-gcc -march=athlon -pipe -O2 -Wl,-O1 -Wl,--as-needed --prin t-file-name=crtendS.o` /var/tmp/portage/sys-libs/glibc-2.32-r3/work/build-x86-i686-pc-linux-gnu-nptl/csu/crtn.o Same error with glibc-2.31-r7. Does it happen for you in non-parallel build? Say, in MAKEOPTS=-j1 mode? I don't see `rt` mentioned anywhere directly and I suspect it might come from libgd.so. If it comes from there then 'USE=-gd emerge -v1 glibc' is worth a try to see if it helps. glibc-2.30-r9 installs fine. glibc-2.32-r3 still fails with the same error, after I installed glibc-2.30-r9. glibc-2.32-r3 installed fine with USE=-gd. After reinstalling gd-2.3.0, installing glibc-2.32-r3 (with USE=gd) worked fine. I tried to reproduce the failure in x86 chroot with USE=gd and glibc 2.30-r9->2.32-r3 and had no problems. I wonder why you had librt involved at all. Do you happen to have a backup of libgd before you rebuilt it? Unfortunately I don't have any backup. Maybe it was relevant that libgd was compiled using glibc-2.27-r6 before. It might be. But it looks unlikely as libgd (and at a glance any of it's depends) does not have time-related symbols. Could it be that you explicitly used -lrt in LDFLAGS at some point? > Could it be that you explicitly used -lrt in LDFLAGS at some point?
No.
Btw, why do you think that libgd is the cause at all? Why do you think this comes from libgd?
Maybe the USE flag gd had some other effects on glibc which made it compile fine?
(In reply to Albert Zeyer from comment #14) > > Could it be that you explicitly used -lrt in LDFLAGS at some point? > > No. > > Btw, why do you think that libgd is the cause at all? Why do you think this > comes from libgd? It might come from somewhere else as well, like libpng or libz (both sound equally unlikely). You #c10 comment suggest rebuilding it might have a positive effect. That's a best pointer we have. I don't remember of a similar being ever reported to gentoo bugtracker. > Maybe the USE flag gd had some other effects on glibc which made it compile > fine? My understanding of USE=gd is to only enable memusagestat binary and link it against -lgd -lpng -lz -lm and nothing else: https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/Makefile;h=39ffaa7161d3027905d6eef349a32b12164e822f;hb=HEAD#l149. But maybe there was some subtle unintended side-effect. In my #c10, I also already had the glibc-2.32-r3 installed (without gd) from before. Maybe that was relevant? The diff between #c8 and #c9 is only that I used USE=-gd. So that definitely plays some role. I don't have a good idea here. Maybe we can close this as not reproducible for now. I was already curious when I got the error that I did not find any similar report on the Internet. But now that it is posted here, maybe someone else stumbles upon it. Yeah. Let's close it as obsolete and let people complain here if it's not true. Then we'll try to investigate broken system in more detail. (In reply to Sergei Trofimovich from comment #17) > Yeah. Let's close it as obsolete and let people complain here if it's not > true. > > Then we'll try to investigate broken system in more detail. I experienced this issue on a Funtoo system I administer rather than Gentoo, but it may still be a useful data point. I was attempting to upgrade from glibc-2.29-r3 to glibc-2.33 with gd-2.3.0 and USE=gd. In order: USE=gd emerge =sys-libs/glibc-2.33 failed emerge =medialibs/gd-2.3.0 succeeded USE=gd emerge =sys-libs/glibc-2.33 failed USE=-gd emerge =sys-libs/glibc-2.33 succeeded emerge =medialibs/gd-2.3.0 succeeded USE=gd emerge =sys-libs/glibc-2.33 succeeded I unfortunately didn't read/think closely enough and didn't make binary backups of gd or glibc before attempting the workaround, but I do have build logs if they are necessary. Investigating the librt dependency, libgd -> libXpm -> libX11 -> libxcb -> libXdmcp -> libbsd -> librt. I have USE=xpm set, which affects gd. I imagine that I could have re-emerged gd without the xpm dependency at step 2 and upgraded directly from glibc 2.29-r3 to 2.33. (In reply to Anthony Low from comment #18) > (In reply to Sergei Trofimovich from comment #17) > > Yeah. Let's close it as obsolete and let people complain here if it's not > > true. > > > > Then we'll try to investigate broken system in more detail. > > I experienced this issue on a Funtoo system I administer rather than Gentoo, > but it may still be a useful data point. I was attempting to upgrade from > glibc-2.29-r3 to glibc-2.33 with gd-2.3.0 and USE=gd. In order: > > USE=gd emerge =sys-libs/glibc-2.33 failed > emerge =medialibs/gd-2.3.0 succeeded > USE=gd emerge =sys-libs/glibc-2.33 failed > USE=-gd emerge =sys-libs/glibc-2.33 succeeded > emerge =medialibs/gd-2.3.0 succeeded > USE=gd emerge =sys-libs/glibc-2.33 succeeded > > I unfortunately didn't read/think closely enough and didn't make binary > backups of gd or glibc before attempting the workaround, but I do have build > logs if they are necessary. > > Investigating the librt dependency, libgd -> libXpm -> libX11 -> libxcb -> > libXdmcp -> libbsd -> librt. I have USE=xpm set, which affects gd. I > imagine that I could have re-emerged gd without the xpm dependency at step 2 > and upgraded directly from glibc 2.29-r3 to 2.33. Yeah, build logs for all the steps above might be useful. Created attachment 691884 [details]
#2 - gd with old glibc
Created attachment 691887 [details]
#3 - glibc with old gd and USE=gd
Created attachment 691890 [details]
#4 - glibc with old gd and USE=-gd
Created attachment 691893 [details]
#5 - gd with new glibc
Created attachment 691896 [details]
#6 - glibc with new gd and USE=gd
I've attached the build logs. I omitted the first glibc build (#1) since it should be "identical" to the second glibc build (#3). Thank you! I don't see anything unusual in the logs, but I think I now understand where the problem comes from. You might want to fix your environment though (see [1.] below). A few observations: 1. 'tc-getREADELF' is not found. It's probably unrelated to the issue at hand but your new glibc build seems to use outdated toolchain-funcs.eclass: > /var/tmp/portage/sys-libs/glibc-2.33/temp/environment: line 1921: tc-getREADELF: command not found This means tour overlay is probably with glibc out-of-sync. 2. Identical 'gd' builds: Both gd build log file: - #2 - gd with old glibc - #5 - gd with new glibc are identical. Which probably means they either did not change or some toolchain behaviour changed. Hard to say without a binary and a reproducer. 3. Identical 'glibc' builds: Both glibc with gd enabled are identical (un to an error): - #3 - glibc with old gd and USE=gd - #6 - glibc with new gd and USE=gd Which is even more confusing. I think this means that memusagestat links directly to bits of local and bits of installed libc: """ x86_64-pc-linux-gnu-gcc -march=native -pipe -ggdb -O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath-link=/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/math:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/mathvec:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/support:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt:/var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl -pie -Wl,-O1 -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/malloc/memusagestat -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/Scrt1.o /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/crti.o `x86_64-pc-linux-gnu-gcc -march=native -pipe -ggdb -O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu --print-file-name=crtbeginS.o` /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/malloc/memusagestat.o -lgd -lpng -lz -lm -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,now /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so.6 /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_nonshared.a -Wl,--as-needed /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so -Wl,--no-as-needed -lgcc `x86_64-pc-linux-gnu-gcc -march=native -pipe -ggdb -O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu --print-file-name=crtendS.o` /var/tmp/portage/sys-libs/glibc-2.33/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/crtn.o """ The important bit here is lacking set of -L... options that point to local libc (librt and friends). All the other tools glibc bulds never link to anything else than libc.so.6 and we don't see a problem. |