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

[Adhemerval Zanella Netto]

On 05/05/26 09:43, Lukasz Stelmach wrote:
> 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.

Right, patches for libc-alpha are expected to be crafted against master branch.
Submission for old releases are usually for backporting and bugfixes, since
it is hard to reason for a new feature against a old release.

> 
>> 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.

I would like also to take a step back and think if this proposed solution would
fit in other scenarios other than Tizen.  For instance, Flatpack and Snap rely 
on user namespace to provide similar isolation, while AppImages uses squasfs plus
LD_LIBRARY_PATH. So my question is why this new scheme is preferable over how
my exploration supervisor idea and/or how current Linux runtime are currently
doing.

I recall some project do patch glibc ld.so.cache logic to solve different 
issues [1] (the 'stat storm' that hits hard on some network files). Other
system went for a different route, like Spark with RPATH / RUNPATH. But
I read that even HPC workloads are moving to user namespace and bind mount
to avoid similar issues.

[1] https://issues.guix.gnu.org/44899#:~:text=%5BPATCH%201%2F3%5D%20gnu,mk%20(dist_patch_DATA)%3A%20Add%20it.