On Tue, Jun 2, 2020 at 2:46 PM Andre McCurdy <armccu...@gmail.com> wrote: > > 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.
If we can get this working and perhaps as a packageconfig this would address concern #1 nicely per distro policies.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139200): https://lists.openembedded.org/g/openembedded-core/message/139200 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] -=-=-=-=-=-=-=-=-=-=-=-