[RFC 1/3] dlconf: Add support for config file for ld.so

[Lukasz Stelmach]

It was 2026-05-04 pon 16:32, when Adhemerval Zanella Netto wrote:
> On 21/04/26 06:00, Łukasz Stelmach wrote:
>> From: Mateusz Moscicki <m.moscicki2@samsung.com>
>> 
>> Configuration allows to specify which ld.so.cache file to use when
>> looking for dependencies for a library or binary from a specific path
>> (note that setting LD_LIBRARY_PATH or RUNPATH will result in the
>> following configuration not being used).
>
> Hi,
>
> This RFC failed to apply [1]. And even after I tried to manually fix it, it
> does not build cleanly with --enable-dconf (most likely due some extra
> object pulling during ld.so build). Did you create the patchset against an
> older glibc version?

Yes, we worked on glibc 2.40. I am sorry, I forgot to mention it.

> I understand this feature make sense in an embedded or multi-stack
> Linux like Tizen, where distinct library subtrees co-exist under
> different directories; and these subtrees have their own versions of
> common libraries.

Yes, that is our approach to integration of vendor BSPs.

> But I have some design concerns that it would require further discussion:
>  
>   1. The --enable-dlconf / #ifdef DLCONF compile-time gate: we try to avoid
>      configure switch that changes the dynamic linker semantics and this
>      ones adds:
>
>      a. A feature that is inaccessible to users if a distro's glibc does
>         not enable it.
>
>      b. two separate ld.so code paths to maintain, test, and audit forever.
>
>      The glibc's precedent for optional features that affect ld.so behavior 
>      (tunables, audit hooks, hwcaps) is to make them runtime-conditional, not 
>      compile-time-conditional.

ACK.

[…]

>   2. The two-tier config format adds operational fragility: the extra dat file
>      adds extra maintenance and code complexity. Compare to how ldconfig works: 
>      it is explicitly integrated into the package manager and init system. This
>      feature introduces a second pipeline with no such integration.

The reason it looks like a separate pipeline is because we don't
want/need that level of integration. Although in Tizen we package
software in RPMs, they are not distributed. We use images and it is the
image building process where we put stuff together. That's where we come
from. Of course for the patches to be acceptable for wider audience
we'll try to come up with something more in line with traditional
setups.

>   3. No namespace awareness: The feature uses three module-level globals
>      (conf_data, cache_list, g_caches/g_dlopen_paths) with no awareness of glibc's 
>      link-map namespaces (dlmopen creates separate namespaces). A process using 
>      multiple namespaces will have all of them share the same dlconf policy, which
>      may not be the intent.

Thanks a lot for your detailed review. This is just to acknowledge, that we've
received it and we will be preparing v2 as well as we will answer your
question in details in the next message.

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260505/9bc22520/attachment.sig>