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.