Hi,
when debugging a missing library issue on a ptxdist-2016.01.0 system
built with the latest OSELAS.Toolchain, glibc and
arm-v7a-linux-gnueabihf as toolchain target, I stumbled across the
following strange library search paths, which are searched over and over
again for each and every process which is linked dynamically to libc.
(Watch out for the stat64 and open syscalls in the strace of busybox
/bin/true below)
$ strace /bin/true
strace /bin/true
execve("/bin/true", ["/bin/true"], [/* 15 vars */]) = 0
brk(0) = 0x14b6000
uname({sysname="Linux", nodename="tux", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x76ffd000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/lib/tls/v7l/neon/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
stat64("/lib/tls/v7l/neon/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or
directory)
open("/lib/tls/v7l/neon/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/lib/tls/v7l/neon", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/v7l/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/lib/tls/v7l/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/v7l/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/tls/v7l", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/neon/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/lib/tls/neon/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/neon/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
stat64("/lib/tls/neon", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/tls/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/tls", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/v7l/neon/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/lib/v7l/neon/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/v7l/neon/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
stat64("/lib/v7l/neon", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/v7l/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/v7l/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/v7l/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/v7l", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/neon/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
stat64("/lib/neon/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/neon/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/neon", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat64("/lib/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
(...)
Finally after 15 unsuccessful attempts to locate libc at strange
non-existing paths like /lib/tls/neon/vfp, etc. it is found at the
default location under /lib. Surprise ;)
Is there a way to tell glibc during the toolchain build process that it
should not search at those paths (which do not exist on our systems
anyway) but instead only search, let's say, in /lib and /usr/lib ?
If we have over 30 useless syscalls just for a simple call to /bin/true
/bin/false or /bin/ls, this wastes a lot of resources for nothing.
Especially, if many shell scripts are used on the system.
Adding ldconfig and creating a /etc/ld.so.cache would also be a
possibility but I prefer to just remove those strange search paths.
Would be great to know how to change them. Any ideas?
Thanks,
Clemens
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
