Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Graeme Gregory]

git version control wrote:
> Module: openembedded.git
> Branch: org.openembedded.dev
> Commit: 056a67f6070c5ea561acb65049b551e24f3b7eb6
> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=056a67f6070c5ea561acb65049b551e24f3b7eb6
>
> Author: Stanislav Brabec <utx@penguin.cz>
> Date:   Wed Aug 26 21:05:59 2009 +0000
>
> glibc: Install ld.so.conf, so ldconfig does not complain.
>
>   
I have the feeling this is the reversal of a previous decision to remove 
ld.so.conf from rootfs.

Also its a core change and I don't see any Acked-By:

Graeme

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Phil Blundell]

On Thu, 2009-08-27 at 07:58 +0100, Graeme Gregory wrote:
> git version control wrote:
> > Module: openembedded.git
> > Branch: org.openembedded.dev
> > Commit: 056a67f6070c5ea561acb65049b551e24f3b7eb6
> > URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=056a67f6070c5ea561acb65049b551e24f3b7eb6
> >
> > Author: Stanislav Brabec <utx@penguin.cz>
> > Date:   Wed Aug 26 21:05:59 2009 +0000
> >
> > glibc: Install ld.so.conf, so ldconfig does not complain.
> >
> >   
> I have the feeling this is the reversal of a previous decision to remove 
> ld.so.conf from rootfs.
> 
> Also its a core change and I don't see any Acked-By:

Agreed, that change seems wrong.  If a particular DISTRO wants to ship
ld.so.conf in glibc then that's fine, but it shouldn't be standard and
definitely not without a USE_LDCONFIG conditional.

p.

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Stanislav Brabec]

Phil Blundell wrote:
   
> > I have the feeling this is the reversal of a previous decision to remove 
> > ld.so.conf from rootfs.
> > 
> > Also its a core change and I don't see any Acked-By:
> 
> Agreed, that change seems wrong.  If a particular DISTRO wants to ship
> ld.so.conf in glibc then that's fine,

I just reverted this change. Sorry for that. It looked just like a typo:
ld.so.conf was copied to source tree and the patch suppressing the
warning on missing ld.so.conf (ldconfig.patch) was commented out...

If missing ld.so.conf is intended, ld.co.sonf could be removed from
recipes and ldconfig.patch (or at least its last chunk) should be
applied.

> but it shouldn't be standard and
> definitely not without a USE_LDCONFIG conditional.

It was inside USE_LDCONFIG, if ldconfig is installed.

By the way, what is the benefit of not using ldconfig? Strace shows 15
extra failing library lookups for each library.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf , so ldconfig does not complain .

[Holger Hans Peter Freyther]

On Thursday 27 August 2009 13:32:31 Stanislav Brabec wrote:
> Phil Blundell wrote:
> > > I have the feeling this is the reversal of a previous decision to
> > > remove ld.so.conf from rootfs.
> > >
> > > Also its a core change and I don't see any Acked-By:
> >
> > Agreed, that change seems wrong.  If a particular DISTRO wants to ship
> > ld.so.conf in glibc then that's fine,
>
> I just reverted this change. Sorry for that. It looked just like a typo:
> ld.so.conf was copied to source tree and the patch suppressing the
> warning on missing ld.so.conf (ldconfig.patch) was commented out...
>
> If missing ld.so.conf is intended, ld.co.sonf could be removed from
> recipes and ldconfig.patch (or at least its last chunk) should be
> applied.
>
> > but it shouldn't be standard and
> > definitely not without a USE_LDCONFIG conditional.
>
> It was inside USE_LDCONFIG, if ldconfig is installed.
>
> By the way, what is the benefit of not using ldconfig? Strace shows 15
> extra failing library lookups for each library.

did we disable the hwcaps patch once again?

z.

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Phil Blundell]

On Thu, 2009-08-27 at 13:32 +0200, Stanislav Brabec wrote:
> By the way, what is the benefit of not using ldconfig? Strace shows 15
> extra failing library lookups for each library.

It depends on your DISTRO configuration really: some people will be
better off without it and some people won't.

If your library paths are set up right, the dynamic linker will find the
library in the first place it searches and hence there's no need for the
cache file.  In that situation, the extra time taken to stat and map the
cache is just a waste.  This is one of the reasons that the micro
distribution folds out /usr and installs all libraries into /lib.

Also, ldconfig itself is a large-ish binary, especially if it's
statically linked, and represents a waste of scarce flash space on small
systems.

Also also, keeping the cache up to date requires that you either have a
writeable rootfs or that you store the cache in RAM disk; in the latter
case you would need to generate it on every boot, which might be an
unwelcome slowdown.

On the other hand, if you find yourself obliged to spread the libraries
across many directories, and/or if you plan to use hwcap-based
searching, installing ldconfig might indeed be a net win.  If you're
seeing 15 path lookups for each library load then it sounds like your
system falls into this category.

p.

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Stanislav Brabec]

Phil Blundell wrote:
> On Thu, 2009-08-27 at 13:32 +0200, Stanislav Brabec wrote:
> > By the way, what is the benefit of not using ldconfig? Strace shows 15
> > extra failing library lookups for each library.

> On the other hand, if you find yourself obliged to spread the libraries
> across many directories, and/or if you plan to use hwcap-based
> searching, installing ldconfig might indeed be a net win.  If you're
> seeing 15 path lookups for each library load then it sounds like your
> system falls into this category.

No, it is not my case. My image is just a plain angstrom-2008.1. These
15 directories don't exist. With ld.so.cache I don't see these lookups.

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/var/run/ld.so.cache", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/lib/tls/v5l/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v5l/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/tls/v5l/fast-mult/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v5l/fast-mult", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/tls/v5l/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v5l/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/tls/v5l/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v5l", 0xbedce3f0)      = -1 ENOENT (No such file or directory)
open("/lib/tls/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/tls/fast-mult/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/fast-mult", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/tls/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/half", 0xbedce3f0)     = -1 ENOENT (No such file or directory)
open("/lib/tls/libm.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0xbedce3f0)          = -1 ENOENT (No such file or directory)
open("/lib/v5l/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v5l/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/v5l/fast-mult/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v5l/fast-mult", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/v5l/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/v5l/half", 0xbedce3f0)     = -1 ENOENT (No such file or directory)
open("/lib/v5l/libm.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
stat64("/lib/v5l", 0xbedce3f0)          = -1 ENOENT (No such file or directory)
open("/lib/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
open("/lib/fast-mult/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/fast-mult", 0xbedce3f0)    = -1 ENOENT (No such file or directory)
open("/lib/half/libm.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/half", 0xbedce3f0)         = -1 ENOENT (No such file or directory)
open("/lib/libm.so.6", O_RDONLY)        = 3

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Phil Blundell]

On Thu, 2009-08-27 at 15:56 +0200, Stanislav Brabec wrote:
> Phil Blundell wrote:
> > On the other hand, if you find yourself obliged to spread the libraries
> > across many directories, and/or if you plan to use hwcap-based
> > searching, installing ldconfig might indeed be a net win.  If you're
> > seeing 15 path lookups for each library load then it sounds like your
> > system falls into this category.
> 
> No, it is not my case. My image is just a plain angstrom-2008.1. These
> 15 directories don't exist. With ld.so.cache I don't see these lookups.
> 
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> open("/var/run/ld.so.cache", O_RDONLY)  = -1 ENOENT (No such file or directory)
> open("/lib/tls/v5l/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/lib/tls/v5l/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)

Right, so it appears that your distro is indeed using hwcap-based
library searches; as I said above, this is one of the situations where
ldconfig is a benefit.

p.

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Graeme Gregory]

Phil Blundell wrote:
> On Thu, 2009-08-27 at 15:56 +0200, Stanislav Brabec wrote:
>   
>> Phil Blundell wrote:
>>     
>>> On the other hand, if you find yourself obliged to spread the libraries
>>> across many directories, and/or if you plan to use hwcap-based
>>> searching, installing ldconfig might indeed be a net win.  If you're
>>> seeing 15 path lookups for each library load then it sounds like your
>>> system falls into this category.
>>>       
>> No, it is not my case. My image is just a plain angstrom-2008.1. These
>> 15 directories don't exist. With ld.so.cache I don't see these lookups.
>>
>> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
>> open("/var/run/ld.so.cache", O_RDONLY)  = -1 ENOENT (No such file or directory)
>> open("/lib/tls/v5l/fast-mult/half/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
>> stat64("/lib/tls/v5l/fast-mult/half", 0xbedce3f0) = -1 ENOENT (No such file or directory)
>>     
>
> Right, so it appears that your distro is indeed using hwcap-based
> library searches; as I said above, this is one of the situations where
> ldconfig is a benefit.
>   
That would be an accidental Angstrom regression then! Ooops!

Graeme

Re: [oe-commits] Stanislav Brabec : glibc: Install ld.so.conf, so ldconfig does not complain .

[Koen Kooi]

On 27-08-09 08:58, Graeme Gregory wrote:
> git version control wrote:
>> Module: openembedded.git
>> Branch: org.openembedded.dev
>> Commit: 056a67f6070c5ea561acb65049b551e24f3b7eb6
>> URL:
>> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=056a67f6070c5ea561acb65049b551e24f3b7eb6
>>
>>
>> Author: Stanislav Brabec <utx@penguin.cz>
>> Date: Wed Aug 26 21:05:59 2009 +0000
>>
>> glibc: Install ld.so.conf, so ldconfig does not complain.
>>
> I have the feeling this is the reversal of a previous decision to remove
> ld.so.conf from rootfs.

it is.

regards,

Koen