From: "Phil Blundell" <pb@pbcl.net>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Martin Jansa <martin.jansa@gmail.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Richard Purdie <richard.purdie@linuxfoundation.org>,
Khem Raj <raj.khem@gmail.com>,
Andreas Oberritter <obi@opendreambox.org>
Subject: Re: [OE-core] [PATCH] glibc: move ld.so.conf back to main package
Date: Mon, 18 May 2020 14:23:19 +0200 [thread overview]
Message-ID: <20200518122319.GD20108@pbcl.net> (raw)
In-Reply-To: <0397befe-9f5d-a704-be07-00926fd3fffa@prevas.dk>
On Mon, May 18, 2020 at 02:12:43PM +0200, Rasmus Villemoes wrote:
> I'm certainly open to other ways of solving this. But can we agree that
> it is a bug that the ldconfig done at build-time does not take
> /etc/ld.so.conf.d/* into account, and that that should not depend on
> whether one has ldconfig-the-binary on target?
Yes, nowadays that's probably true.
When the USE_LDCONFIG flag (predecessor to the ldconfig DISTRO_FEATURE)
was originally added, the primary usecase was distros that didn't want
any of the ld.so.conf mechanism at all because they knew that the
libraries would always be installed in the first place that ld.so
would look for them. In fact the commit message from when the
DISTRO_FEATURE flag was added basically says as much:
USE_LDCONFIG could previously be set to 0 by distros which do not
require ldconfig or ld.so.conf on the target. Since more and more
recipes may need to respect that option, replace the ad-hoc variable
with a distro feature.
But you're right that there's also a perfectly valid usecase for
folks who want to be able to use ld.so.conf to control the search paths
but don't actually want the ldconfig binary in the rootfs. I guess at
that point the question becomes whether setting both read-only-rootfs
and ldconfig should cause the actual ldconfig binary to be left out
on the grounds that it can't do anything useful on a read-only rootfs,
or whether there ought to be a slightly different flag to represent
the usecase you're interested in.
p.
next prev parent reply other threads:[~2020-05-18 12:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 11:36 [PATCH] glibc: move ld.so.conf back to main package Rasmus Villemoes
2020-05-18 11:55 ` Martin Jansa
2020-05-18 12:12 ` Rasmus Villemoes
2020-05-18 12:23 ` Phil Blundell [this message]
2020-05-18 12:29 ` Andreas Oberritter
2020-05-18 13:25 ` Rasmus Villemoes
2020-05-18 14:36 ` Andreas Oberritter
2020-06-02 9:44 ` [PATCH v2] " Rasmus Villemoes
2020-06-02 10:02 ` ✗ patchtest: failure for glibc: move ld.so.conf back to main package (rev2) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200518122319.GD20108@pbcl.net \
--to=pb@pbcl.net \
--cc=martin.jansa@gmail.com \
--cc=obi@opendreambox.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
--cc=rasmus.villemoes@prevas.dk \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox