On Wed, 2020-06-03 at 13:44 -0700, Andre McCurdy wrote: > On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes > <[email protected]> wrote: > > 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). > > Unless the supplier of your binaries is completely unresponsive (if > so, bad luck) then educating them on the usage of rpath and asking > for > a new release is probably the cleanest solution. > > If you start your special application via a wrapper script which sets > LD_LIBRARY_PATH then it won't be seen by anything else, so the > concerns about other apps messing with it etc should not apply? > > Relying on /etc/ld.so.conf.d/*.conf will certainly work too, but has > two disadvantages: it will add the custom library path globally > instead of just for the special apps and it's not portable (it's not > supported by musl etc - although if you only care about your > proprietary binaries pre-compiled for glibc then that won't matter to > you). > > Anyway, the original patch has been merged, so this now just a side > discussion.
It hasn't, its still in master-next waiting for us to reach a conclusion... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139213): https://lists.openembedded.org/g/openembedded-core/message/139213 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]] -=-=-=-=-=-=-=-=-=-=-=-
