* [ptxdist] Strange system library search paths with OSELAS.Toolchain
@ 2016-02-06 15:33 Clemens Gruber
2016-02-08 8:58 ` Juergen Borleis
0 siblings, 1 reply; 6+ messages in thread
From: Clemens Gruber @ 2016-02-06 15:33 UTC (permalink / raw)
To: ptxdist; +Cc: Michael Olbrich
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [ptxdist] Strange system library search paths with OSELAS.Toolchain
2016-02-06 15:33 [ptxdist] Strange system library search paths with OSELAS.Toolchain Clemens Gruber
@ 2016-02-08 8:58 ` Juergen Borleis
2016-02-09 0:04 ` Clemens Gruber
0 siblings, 1 reply; 6+ messages in thread
From: Juergen Borleis @ 2016-02-08 8:58 UTC (permalink / raw)
To: ptxdist; +Cc: Clemens Gruber
Hi Clemens,
On Saturday 06 February 2016 16:33:55 Clemens Gruber wrote:
> [...]
> stat64("/lib/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
Try to run "ldconfig" on your target and re-check. With some tricks you can do
this with ptxdist at build time as well.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [ptxdist] Strange system library search paths with OSELAS.Toolchain
2016-02-08 8:58 ` Juergen Borleis
@ 2016-02-09 0:04 ` Clemens Gruber
2016-02-09 9:31 ` Juergen Borleis
0 siblings, 1 reply; 6+ messages in thread
From: Clemens Gruber @ 2016-02-09 0:04 UTC (permalink / raw)
To: ptxdist
On Mon, Feb 08, 2016 at 09:58:58AM +0100, Juergen Borleis wrote:
> Hi Clemens,
>
> On Saturday 06 February 2016 16:33:55 Clemens Gruber wrote:
> > [...]
> > stat64("/lib/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
> > open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>
> Try to run "ldconfig" on your target and re-check. With some tricks you can do
> this with ptxdist at build time as well.
Hi Juergen,
do you have an idea on how to disable those paths at toolchain build
time so that I do not even have to run ldconfig on every target?
If there are ptxdist rules for building ldconfig (and running it on the
target / during targetinstall) this would help a lot.
So far, I did not find anything in the upstream OSELAS.Toolchain rules
for glibc. I'll look into adapting the OSELAS.Toolchain build process to
include ldconfig or change the default search paths.
I am curious: Do you also see those weird runtime paths on your ptxdist
projects or is there something wrong with my toolchain / bsp build?
Thanks,
Clemens
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [ptxdist] Strange system library search paths with OSELAS.Toolchain
2016-02-09 0:04 ` Clemens Gruber
@ 2016-02-09 9:31 ` Juergen Borleis
2016-02-09 16:42 ` Clemens Gruber
0 siblings, 1 reply; 6+ messages in thread
From: Juergen Borleis @ 2016-02-09 9:31 UTC (permalink / raw)
To: Clemens Gruber; +Cc: ptxdist
Hi Clemens,
On Tuesday 09 February 2016 01:04:21 Clemens Gruber wrote:
> On Mon, Feb 08, 2016 at 09:58:58AM +0100, Juergen Borleis wrote:
> > On Saturday 06 February 2016 16:33:55 Clemens Gruber wrote:
> > > [...]
> > > stat64("/lib/vfp", 0x7eb4d6c0) = -1 ENOENT (No such file or directory)
> > > open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> >
> > Try to run "ldconfig" on your target and re-check. With some tricks you
> > can do this with ptxdist at build time as well.
>
> do you have an idea on how to disable those paths at toolchain build
> time so that I do not even have to run ldconfig on every target?
Sorry, no idea.
> If there are ptxdist rules for building ldconfig (and running it on the
> target / during targetinstall) this would help a lot.
> So far, I did not find anything in the upstream OSELAS.Toolchain rules
> for glibc. I'll look into adapting the OSELAS.Toolchain build process to
> include ldconfig or change the default search paths.
<path/to/toolchain>/sysroot-<toolchain-name>/sbin/ldconfig
> I am curious: Do you also see those weird runtime paths on your ptxdist
> projects or is there something wrong with my toolchain / bsp build?
I saw these search paths on almost every system, independent of the
distribution (embedded or not).
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [ptxdist] Strange system library search paths with OSELAS.Toolchain
2016-02-09 9:31 ` Juergen Borleis
@ 2016-02-09 16:42 ` Clemens Gruber
2016-02-11 12:10 ` Michael Olbrich
0 siblings, 1 reply; 6+ messages in thread
From: Clemens Gruber @ 2016-02-09 16:42 UTC (permalink / raw)
To: Juergen Borleis; +Cc: ptxdist
Hi Juergen,
On Tue, Feb 09, 2016 at 10:31:22AM +0100, Juergen Borleis wrote:
> <path/to/toolchain>/sysroot-<toolchain-name>/sbin/ldconfig
Very nice, thank you! After running ldconfig on the target, running strace
with /bin/true shows only one access for /etc/ld.so.preload before using
the /etc/ld.so.cache successfully. That's a major improvement! Nearly 30
syscalls less, per process :)
Now I'll just write a little ptxdist rule to call ldconfig once at
initialization (or at every startup? Some distros seem to do that.)
If I ever want to support running opkg on the target, I should probably
have a mechanism to automatically rerun ldconfig in case a library was
changed.
> > I am curious: Do you also see those weird runtime paths on your ptxdist
> > projects or is there something wrong with my toolchain / bsp build?
>
> I saw these search paths on almost every system, independent of the
> distribution (embedded or not).
Maybe we could add a rule to ptxdist to run ldconfig by default on the
target? Assuming that saving syscalls is beneficial for everybody?
Cheers,
Clemens
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ptxdist] Strange system library search paths with OSELAS.Toolchain
2016-02-09 16:42 ` Clemens Gruber
@ 2016-02-11 12:10 ` Michael Olbrich
0 siblings, 0 replies; 6+ messages in thread
From: Michael Olbrich @ 2016-02-11 12:10 UTC (permalink / raw)
To: ptxdist
On Tue, Feb 09, 2016 at 05:42:31PM +0100, Clemens Gruber wrote:
> On Tue, Feb 09, 2016 at 10:31:22AM +0100, Juergen Borleis wrote:
> > <path/to/toolchain>/sysroot-<toolchain-name>/sbin/ldconfig
>
> Very nice, thank you! After running ldconfig on the target, running strace
> with /bin/true shows only one access for /etc/ld.so.preload before using
> the /etc/ld.so.cache successfully. That's a major improvement! Nearly 30
> syscalls less, per process :)
>
> Now I'll just write a little ptxdist rule to call ldconfig once at
> initialization (or at every startup? Some distros seem to do that.)
>
> If I ever want to support running opkg on the target, I should probably
> have a mechanism to automatically rerun ldconfig in case a library was
> changed.
>
> > > I am curious: Do you also see those weird runtime paths on your ptxdist
> > > projects or is there something wrong with my toolchain / bsp build?
> >
> > I saw these search paths on almost every system, independent of the
> > distribution (embedded or not).
>
> Maybe we could add a rule to ptxdist to run ldconfig by default on the
> target? Assuming that saving syscalls is beneficial for everybody?
rc.once would be the right tool for the job. I never bothered with it
because when starting an app with cold caches the startup time difference
was barely measurable.
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-11 12:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-06 15:33 [ptxdist] Strange system library search paths with OSELAS.Toolchain Clemens Gruber
2016-02-08 8:58 ` Juergen Borleis
2016-02-09 0:04 ` Clemens Gruber
2016-02-09 9:31 ` Juergen Borleis
2016-02-09 16:42 ` Clemens Gruber
2016-02-11 12:10 ` Michael Olbrich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox