Re: [musl] How to support symbol versioning for musl?

[Kai Peter <kp@lists.qware.org>]

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