[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c949f3550fe1d4b8fe8d790e608aa8cd@lists.qware.org>
Date: Wed, 20 Apr 2022 10:42:19 +0200
From: Kai Peter <kp@...ts.qware.org>
To: musl@...ts.openwall.com
Subject: Re: How to support symbol versioning for musl?
On 2022-03-28 17:37, Rich Felker wrote:
>
> This is a topic that's come up before. Symbol versioning was
> intentionally not implemented to begin with because it's a really bad
> tool for what it's intended for and we intended not to use it in musl
> itself, but indeed still some things want to use it on their own, and
> at one point there was some wacky use of symbol versioning in
> libgcc_s.so that looked like it was going to be a problem to handle
> without supporting symbol versioning. So there has been talk on and
> off about supporting it in the future, but I think it's still a topic
> members of the community disagree over.
>
> Implementation-wise, supporting versioning requires adding the logic
> to symbol lookups. Right now they use the versym table only to
> determine if the candidate symbol is default-version (that would be
> used by ld), in order not to break linking with libraries that were
> built with versioning. They don't have access to the version requested
> by the reference to the symbol. So additional information would have
> to be passed into the inner lookup loops, where it likely does have
> nontrivial costs for symbol lookup performance.
>
> Lines 244-330 of ldso/dynlink.c are the relevant location where this
> would take place. Making it efficient might also require setting up
> some additional data in advance; I'm not sure. It's been a long time
> since I looked at what it might take to do this.
>
> If actual symbol versioning isn't a hard requirement for what you're
> doing, you might look at alternate ways of achieving what you want.
> The core flaw of symbol versioning is that versions are bound at
> link-time, but the actual version needed comes from what headers the
> consumer of the library was built with at compile-time. A much simpler
> and more-correct version of symbol versioning can therefore be
> achieved just by using the preprocessor to remap identifiers in the
> library's headers:
>
> #define libfoo_funcbar libfoo_funcbar_v2
> ...
>
> Rich
Thanks for your quick reply. I'm not sure if I understood this
versioning thing overall. However your hint to look in dynlink.c was
very useful. I did some changes to musl's pathes anyway and did set the
sys_path now accordingly to my needs. This is fine for this custom
system. It's working perfect.
Kai
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.
