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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138404):
https://lists.openembedded.org/g/openembedded-core/message/138404
Mute This Topic: https://lists.openembedded.org/mt/74289052/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
