You are not logged in.
I'm building my own custom linux distro, and I'm puzzled about why 'ldd /usr/bin/gobject-query' shows "libffi.so.6 => /usr/lib/../lib/libffi.so.6" instead of "libffi.so.6 => /usr/lib/libffi.so.6". Archlinux is the host system for building base packages to set up chroot and rebuild them again inside. When building glib2 outside chroot I get "libffi.so.6 => /usr/lib/libffi.so.6". Building it inside chroot ldd shows "libffi.so.6 => /usr/lib/../lib/libffi.so.6". I know that it's harmless and only a cosmetic issue, but I want to know why there is two dots and how to fix this somehow.. Anyone expert on this matter?
Last edited by ahcaliskan (2015-05-14 04:27:43)
Offline
I'm guessing your LDPATH isn't set correctly. Are you using a /lib -> usr/lib symlink?
Offline
Scimmia: Yes I am. /lib points to usr/lib. How do you find out if LDPATH is set at all?
edit: (btw, if you mean LD_LIBRARY_PATH, then it's not set at all.)
Last edited by ahcaliskan (2015-05-13 18:58:05)
Offline
Yeah, that's what I meant. When it's not set, the linker uses the defaults; unfortunately that's getting beyond my knowledge. Check how your glibc is being built vs how Arch builds it.
Offline
I've tried installing Arch's own glibc into the chroot, and it gives me still the same result. I don't think it's the glibc, I build it with the same configuration as Arch do. As you said, it's something to do with the linker not using /usr/lib by default or that /usr/lib/../lib can mean /usr/lib64. It seems that this issue is the trickiest one.
edit: I've installed Arch's own gcc and binutils into the chroot as well, and still the same result. 'gcc --print-search-dirs | grep ^libraries' inside and outside the chroot gives the same library directories.
Last edited by ahcaliskan (2015-05-13 19:41:17)
Offline
I'm building my own custom linux distro, and I'm puzzled about why 'ldd /usr/bin/gobject-query' shows "libffi.so.6 => /usr/lib/../lib/libffi.so.6" instead of "libffi.so.6 => /usr/lib/lib/libffi.so.6"
[emphasis mine]
I think you mean /usr/lib/libffi.so.6, since that would be the canonical version of /usr/lib/../lib/libffi.so.6. On my system, at least, /usr/lib/lib/ doesn't exist and I would be surprised to find any libraries there.
If /usr/lib/../lib/libffi.so.6 shortens to /usr/lib/lib/libffi.so.6 for you, you have something quite strange going on.
Last edited by Trent (2015-05-14 00:59:10)
Offline
Trent: thanks for pointing it out. I meant /usr/lib/libffi.so.6 so. As you know, I don't have /usr/lib/lib directory on my custom system as well.
Last edited by ahcaliskan (2015-05-14 04:42:09)
Offline
/usr/lib/../lib/ is equivalent to /usr/lib/, so what's the problem?
Offline
it's a cosmetic problem I want to know why /usr/lib is overriden by /usr/lib/../lib.
Last edited by ahcaliskan (2015-05-14 07:08:52)
Offline
What's in your /etc/ld.so.conf ?
Here's mine (Gentoo):
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/lib64
/usr/lib64
/usr/local/lib64
/lib
/usr/lib
/usr/local/lib
include ld.so.conf.d/*.conf
Arch:
#
# /etc/ld.so.conf
#
include /etc/ld.so.conf.d/*.conf
# End of file
As you can see, Gentoo's ld.so.conf is more interesting. Running "ldd /bin/bash" outputs:
linux-vdso.so.1 (0x00007ffeac4ea000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f118f80b000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f118f5ac000)
libc.so.6 => /lib64/libc.so.6 (0x00007f118f1ff000)
/lib64/ld-linux-x86-64.so.2 (0x00007f118fa5d000)
Offline
Based on Archlinux, my ld.so.conf is practically the same:
#
# /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
Offline
Do something similar to what Gentoo does by default in ld.so.conf. It may be necessary to rebuild software to see the effect of the changed conf.
Offline
I did add library paths to ld.so.conf and rebuilt glib2 but ldd still shows the same result.
Offline
Offline
thanks for trying, I've been pondering about this for more than one week, and still no solution..
Offline