On Thu, Jun 4, 2020 at 5:43 AM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2020-06-03 at 13:44 -0700, Andre McCurdy wrote:
> > 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.
>
> It hasn't, its still in master-next waiting for us to reach a
> conclusion...
OK. The discussion has moved on to the details of Rasmus's use case,
but I can try to summarise the details related to the actual patch...
The patch fixes the problem that if the ldconfig distro feature is
disabled, then the config file needed by ldconfig will not be present
in the rootfs when ldconfig is run at build time (and so ld.so.cache
may not be correctly generated). The change to move ldconfig and its
config file into a separate package didn't account for the fact that
the config file is used at build time, but the underlying problem was
there before that too (before the separate package, the config file
was simply deleted).
The risk of an incorrectly generated ld.so.cache is a bug, so it
should be fixing unconditionally (ie it should not be tied to any
PACKAGECONFIG or new distro config option).
The fix being proposed is simply to always leave the config file in
the rootfs, so it's always there when ldconfig is run at build time.
Doing so seems safe enough. Since the config file is only parsed by
ldconfig, there's no run time performance penalty of leaving it around
- it will just be ignored if there's no ldconfig in the rootfs to use
it.
There's a genuine bug and I don't see an obviously better fix, so I
think the patch should be merged.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139231):
https://lists.openembedded.org/g/openembedded-core/message/139231
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]
-=-=-=-=-=-=-=-=-=-=-=-
