Emerging of libXpm-3.5.7 fails. I've already tried running revdep-rebuild as specified by bug 128069 And have also tried re-emerging libX11 as specified by bug 251822 Reproducible: Always Steps to Reproduce: 1.emerge libXpm 2. 3. Actual Results: emake failed Expected Results: Successful emerge
Created attachment 192362 [details] build.log
Created attachment 192363 [details] emerge --info
Created attachment 192365 [details] config.log
What gives "ldd /usr/lib64/libX11.so"?
(In reply to comment #4) > What gives "ldd /usr/lib64/libX11.so"? > ServerContinent ~ # ldd /usr/lib64/libX11.so linux-vdso.so.1 => (0x00007fffdedfb000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f0ed681e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f0ed6618000) libc.so.6 => /lib/libc.so.6 (0x00007f0ed62c2000) /lib64/ld-linux-x86-64.so.2 (0x00007f0ed6d3d000)
On my system it's linked against libdl... $ ldd /usr/lib64/libX11.so linux-vdso.so.1 => (0x00007fff8a9fe000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f2c823ff000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f2c821f9000) libdl.so.2 => /lib/libdl.so.2 (0x00007f2c81ff4000) libc.so.6 => /lib/libc.so.6 (0x00007f2c81c9f000) /lib64/ld-linux-x86-64.so.2 (0x00007f2c82937000)
please paste the output of "readelf -d /usr/lib64/libX11.so" and of "emerge libX11 -pv" Thanks
Oh and please attach the full build.log of : FEATURES="keeptemp" emerge -1 libX11 Thanks
ServerContinent / # readelf -d /usr/lib64/libX11.so Dynamic section at offset 0x10cb70 contains 24 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libXau.so.6] 0x0000000000000001 (NEEDED) Shared library: [libXdmcp.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libX11.so.6] 0x000000000000000c (INIT) 0x1de08 0x000000000000000d (FINI) 0xafdc8 0x0000000000000004 (HASH) 0x1c8 0x000000006ffffef5 (GNU_HASH) 0x2718 0x0000000000000005 (STRTAB) 0xcf18 0x0000000000000006 (SYMTAB) 0x4e78 0x000000000000000a (STRSZ) 22990 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000003 (PLTGOT) 0x30cfe8 0x0000000000000002 (PLTRELSZ) 15696 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x1a0b8 0x0000000000000007 (RELA) 0x133e0 0x0000000000000008 (RELASZ) 27864 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x133a0 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x128e6 0x000000006ffffff9 (RELACOUNT) 930 0x0000000000000000 (NULL) 0x0 ServerContinent / # emerge libX11 -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libX11-1.1.5 USE="ipv6 -debug -xcb" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
Created attachment 192523 [details] build.log of FEATURES="keeptemp" emerge -1 libX11
[snip] checking if run-time linking is supported... checking for library containing dlopen... no checking for library containing shl_load... no yes checking if loadable i18n module support should be enabled... no [snip] That's not good, looks like your libdl.so is busted. You might want to reemerge glibc. Thanks
I've re-emerged glibc, and then re-emerged libX11 and libXpm. Unfortunately it doesn't seem to make a difference. when doing ldd /usr/lib64/libX11.so it still does not link to libdl.so.2
Honestly, I have no idea but this definitely not an X11 issue, probably a toolchain one. @Bugwranglers, have you seen something like this before? Keeping ourselves as CC. Thanks
Could you please attach the config.log for libX11?
and any chance you are using forced --as-needed?
I am not sure where I can find the config.log of libX11, I dont think that one was generated. And No, I'm not using --as-needed
Ah sorry, you need FEATURES="keeptemp keepwork" emerge -1 libX11, since it is in the work directory.
Created attachment 192763 [details] config.log of libX11
configure:4079: checking for ld used by x86_64-pc-linux-gnu-gcc configure:4146: result: /mnt/sda/usr/x86_64-pc-linux-gnu/bin/ld Do you have some other system on /mnt/sda? Does it work if you unmount it?
/mnt/sda/usr is part of the same gentoo installation as the rest of the directories. I wanted to have /usr and /home on the same hard drive, so before I extracted my stage 3 tarball, I symbolically linked /usr to /mnt/sda/usr, and then I symbolically linked /home to /mnt/sda/home.
If it will make things easier, I will give permission for the gentoo team to SSH into my box.
Is this bug still active, or should I just format?
Honestly, I'm out of ideas. I have no idea why this is failing, but I have a hunch that /usr should not be a symlink. In any case, this is not an X-specific bug. Thanks
sure enough... I'm guessing that the symbolic links are causing the issue here. I wish there was some way to have multiple directories on the same partition, but seems like I'm out of luck. Thanks for all the help.