From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3424 invoked from network); 20 Apr 2022 08:42:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2022 08:42:40 -0000 Received: (qmail 12247 invoked by uid 550); 20 Apr 2022 08:42:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 12212 invoked from network); 20 Apr 2022 08:42:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Apr 2022 10:42:19 +0200 From: Kai Peter To: musl@lists.openwall.com In-Reply-To: <20220328153707.GE7074@brightrain.aerifal.cx> References: <20220328153707.GE7074@brightrain.aerifal.cx> Message-ID: X-Sender: kp@lists.qware.org User-Agent: Roundcube Webmail/1.3.2 Subject: Re: [musl] 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