On 02/06/2020 23.46, Andre McCurdy wrote: > On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via > lists.openembedded.org <[email protected]> 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?
Pre-compiled proprietary binaries/libraries that go in /opt/<vendor>/..., just as /opt is meant for (and no, we can't just install them to /usr/lib, /usr/bin etc - partly because they contain hard-coded absolute paths, but also due to some not-entirely-techical reasons). So there's an /etc/ld.so.conf.d/<vendor>.conf that needs to be picked up. > 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. We don't control the compilation, so rpath is out. We did consider LD_LIBRARY_PATH, but figured that the ld.conf solution is more robust (no problems with setuid binaries or an application that misguidedly sanitizes the environment for subprocesses). Rasmus
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139149): https://lists.openembedded.org/g/openembedded-core/message/139149 Mute This Topic: https://lists.openembedded.org/mt/74625854/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
