Date: Tue, 14 Nov 2023 16:35:06 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: Eleanor Bartle <eleanor@...anor-nb.com> Subject: Re: Care about Symbol Namespacing? Am Tue, Nov 14, 2023 at 02:33:15PM +1100 schrieb Eleanor Bartle: > 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. Actually, no. The big overarching question is what you would hope to achieve with that feature. As I understand it, it is essentially what Windows does with the Import Directory, where you specify for each symbol what object it comes from. This would completely break linking semantics as of today. It's not that it isn't supported with static linking, it's that it would break existing workflows. Currently, in dynamically linked applications you can set LD_PRELOAD to overload symbols existing in otherwise loaded libraries, even libc symbols. This is useful to temporarily run an application with a different malloc() implementation, for example, or try out how much vectorized mem* functions would impact the run time. You can also use these approaches with static linking, but it would require re-linking each time. Adding such an extension would break this. Now libc symbols could only come from libc, and LD_PRELOAD wouldn't work anymore. And for no real benefit, or at least I can't see one. Ciao, Markus
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.