I see. So to justify such a feature there'd need to be an analogous one for static archives. Yeah, that's...ugly. I can begin to imagine such a mechanism but it twists everything out of shape. Not worth it.

On Tue, 14 Nov 2023, at 14:10, Rich Felker wrote:
> On Tue, Nov 14, 2023 at 01:32:02PM +1100, Eleanor Bartle wrote:
> > [please cc]
> > 
> > ELF doesn't have a standard equivalent of Mach-O's Two-Level
> > Namespace, but one can be grafted on, as Solaris does with Direct
> > Binding. I've inquired about this on IRC and the objections raised
> > against it concern moving symbols between or coalescing shared
> > objects without breaking dependent binaries. What I'm wondering is,
> > is it worth thinking about a symbol namespacing system that accounts
> > for this? Would the robustness benefits of such a system be worth
> > the specification complexity?
> > 
> > To be clear, I don't have such a proposal on hand, and it would take
> > me a while to get one ready (and a while more to work out all the
> > kinks I'll inevitably miss); I have the ghost of an idea involving
> > components specifying interface names rather than filenames, which
> > ld.so could then map to shared objects potentially non-injectively,
> > but I don't know the fine details of implementation. This message is
> > mainly to gauge if leadership is at all interested in the broad
> > idea, to determine if even thinking about it is worth my time.
> 
> The lack of this in ELF was by design, with the intent to give dynamic
> linking semantics equivalent to static linking. This is also aligned
> with the musl values of treating static linking as first-class (not
> having functionality that doesn't work, or behaves wrong/differently,
> in static-linked programs). I don't want to see something like this in
> ELF, and it's not something I would support adding to musl even if
> there were an ELF extension for it.
> 
> As you noted, there are also concrete things that would have been
> impossible (? at least difficult, and contingent on details) to fix
> with such a system, like glibc moving symbols that wrongly ended up in
> librt.so or libpthread.so to libc.so.
> 
> Rich
>