Re: [musl] Care about Symbol Namespacing?

[Rich Felker <dalias@libc.org>]

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