On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes
<rasmus.villem...@prevas.dk> 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 <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?
>
> 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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139197):
https://lists.openembedded.org/g/openembedded-core/message/139197
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]
-=-=-=-=-=-=-=-=-=-=-=-
