On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via
lists.openembedded.org <pb=pbcl....@lists.openembedded.org> wrote:
>
> On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
> > I understand the concern, I am a little torn on this as adding in too
> > many different controls and options complicates the test matrix and
> > makes things harder for users.
> >
> > You're effectively suggesting a new DISTRO_FEATURE to control this? or
> > maybe better, perhaps a glibc PACKAGECONFIG?
>
> Yes, right. I don't think it need be a DISTRO_FEATURE because nothing
> outside glibc needs to care.
>
> Here are the scenarios that I think matter, ordered from simplest to
> most complex:
>
> 1. Immutable filesystem, every library installed in the place where
> ld.so would first look for it anyway (i.e. everything in {/usr}/lib).
> In this case, we don't want ldconfig (because it can never do anything
> useful), we don't want ld.so.cache and we don't want ld.so.conf
> because they would cause ld.so to do extra file loads and computation
> but end up with the same result that it would anyway.
>
> 2. Immutable filesystem but some libraries are in places that ld.so
> wouldn't automatically know about. In this case we do want ld.so.conf
> and ld.so.cache, but we still don't want ldconfig.
>
> 3. Mutable filesystem where arbitrary binaries can be installed in
> arbitrary places. It's probably debatable whether ldconfig is needed
> in all these cases, but clearly it's needed in some and I think at
> this point it can be left to a DISTRO decision how exactly they want
> to optimize things.
>
> I think right now oe-core supports #1 and #3. The proposed patch
> seems to be aimed at #2, which is a completely valid usecase,
It seems like a weird corner case to me. Where do these libraries come
from and why can't they be moved or symlinked into a standard path?
If they are somehow special and only used by special applications then
setting rpath or using LD_LIBRARY_PATH just for those applications
would seem to be a better solution than enabling them globally.
> but
> my concern is that we don't want to pessimize #1 in the process.
>
> There is a whole parallel discussion to be had about the merits
> or otherwise of ld.so's hwcaps mechanism. meta-micro has been
> carrying a patch for about a decade to turn all that stuff off,
> on the grounds that it's just a loss on any kind of embedded
> environment. Maybe I should make some effort to get it upstream
> as an option.
Note also that glibc already has a build time option to completely
disable support for ldconfig:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac#l89
Sadly it's not usable in recent versions of glibc (setting
use_ldconfig=no results in a build failure due to some seemingly
unrelated missing build dependency which I haven't had time to dig
into yet) but it worked well for OE 2.2 and gave a noticeable
reduction in glibc code size.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139134):
https://lists.openembedded.org/g/openembedded-core/message/139134
Mute This Topic: https://lists.openembedded.org/mt/74625854/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
