[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Nov 2023 14:33:15 +1100
From: "Eleanor Bartle" <eleanor@...anor-nb.com>
To: "Rich Felker" <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Care about Symbol Namespacing?
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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
