From nobody Fri Feb 2 21:10:02 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRT1n6F7Vz58HDN for ; Fri, 2 Feb 2024 21:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRT1n3QTgz55CQ; Fri, 2 Feb 2024 21:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 412LA32n017234; Fri, 2 Feb 2024 13:10:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 412LA32n017234 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706908203; bh=Cbuf1dWaTExmec1JkXgKhPjvYT7jHkM8+xm/uEAovHU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=T+WrbCYDgw9CkQna59zcDIWtICQUzv8NmAwURHUVxY/HPawDFteqKkjl4ZDyAKnA8 DRXmWKv26d4y5jc7+b6y5znnZbLV04XmsZ951hFDHXTnoDPFmzHyKUzB3FAzCWXwxc ge1ZJdaDv1QDZEwxqbiTmGJqpdVx3IguOvwXA//nDwBf77qCleJplXgC0MbPtxn2RV e7KC5mdaW//TB7uEh3L6d7oVqBBF8Uk2NEwiyRoJWn1iHK6HhikrHiu/zI+wQis6C3 SzHpiwvuyXceccw5JU79FN7G27SF/KiTu0pZn1GERb6zdCnwXyO8KgWmIFS52u6NMF fibZj4FuS+rnw== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 412LA2hC017233; Fri, 2 Feb 2024 13:10:02 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Feb 2024 13:10:02 -0800 From: Steve Kargl To: Konstantin Belousov Cc: Mike Karels , Dimitry Andric , FreeBSD CURRENT Subject: Re: llvm ld vs binutils ld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TRT1n3QTgz55CQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote: > On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote: > > > > Thanks for the explanation, but I think I now have a conundrum. > > Suppose I have two shared libraries libfoo.so and libbar.so, and > > suppose bah@@XXX_1.0 is in libbar.so's symbol map. If my main > > program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar', > > then the linker finds bah@XXX_1.0. > > > > Now suppose a developer adds a new procedure to libfoo.so and she > > just so happens to name her new function bah() with a symbol map > > entry of bah@YYY_a.b. > > > > Which bah@ is linked when rebuilding or loading 'z'? Does it > > depend on the search order for ld-config.so.1? > > In the 'z' binary either bah@XXX_1.0 or bah@YYY_1.0 is specified as > the symbol to resolve at the call site. Dynamic linker searches for > corresponding versioned symbol in the global namespace, typically. > > So now the question is reduced to what version of the symbol bah get > recorded into the 'z' binary. It is done by static linker, which looks > up symbols linearly in the order of object files and libraries specified > on the command line (*). If you did 'cc -o z main.c -lfoo -lbar', and > both libfoo.so and libbar.so provided the bah symbol, the first found > definition is recorded, together with its version. The final answer > is lookup finds bah in libfoo.so and bah@YYY_1.0 is recorded. > > * There are many ways to direct static linker to find specific version > of the symbol, changing the default behavior. Thank you. This essentially confirms my fears. -- Steve