From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zmcc-2-mx.zmailcloud.com (zmcc-2-mx.zmailcloud.com [52.37.197.7]) by sourceware.org (Postfix) with ESMTPS id 641E33972446 for ; Wed, 28 Oct 2020 14:35:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 641E33972446 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=symas.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hyc@symas.com Received: from zmcc-2.zmailcloud.com (zmcc-2-mta-1.zmailcloud.com [146.148.52.56]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-2-mx.zmailcloud.com (Postfix) with ESMTPS id 788E24055F; Wed, 28 Oct 2020 09:35:54 -0500 (CDT) Received: from zmcc-2.zmailcloud.com (localhost [127.0.0.1]) by zmcc-2-mta-1.zmailcloud.com (Postfix) with ESMTPS id F2CD3D00D0; Wed, 28 Oct 2020 09:35:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-2-mta-1.zmailcloud.com (Postfix) with ESMTP id DAC01D0046; Wed, 28 Oct 2020 09:35:53 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 zmcc-2-mta-1.zmailcloud.com DAC01D0046 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symas.com; s=37C7994C-28CA-11EA-A30F-68F90BB9D764; t=1603895753; bh=2DWKM9iAlmU2ai383Zyjucc+eOIlZ6q8/s36lMsxVSY=; h=To:From:Message-ID:Date:MIME-Version; b=nWcSUWjaBN5g1hilBRIRaSFc1LZcnpBYcMrrWrTH9+Z0cHq213SVM7ubJHdh7pGdh f8S01F/B40JuxNKKdvBu+XSnPOY4b4l+BNIhvQaWbZ5/V/ntznLvD5WbmDsMfUXr4I zS5bdPwzz/KT83Pw/2xUR1rP5jVe1bAbXiByRhiWfbwOyWqn2dQPLxqNFCovP6wT7Z hWkIb8q0O3ljVYHoSA2Kxt42OraPWENQaR+qWUfZUVoXonGdftD8a/RoD6HYgrvjc+ LFAGn7PwLARrfFLLXuy0rvtj6oQSqB6khqHWRLZtc5NFVNXgBvtvikNrL1VImS7G3w BLaRjAzCJquFw== Received: from zmcc-2.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-2-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wf64SBvpnBhQ; Wed, 28 Oct 2020 09:35:53 -0500 (CDT) Received: from [192.168.1.155] (unknown [84.203.28.68]) by zmcc-2-mta-1.zmailcloud.com (Postfix) with ESMTPSA id 08155C000B; Wed, 28 Oct 2020 09:35:52 -0500 (CDT) Subject: Re: [PATCH] dependency list for static libraries To: Peter Smith , Fangrui Song Cc: "binutils@sourceware.org" References: From: Howard Chu Message-ID: <456f47ed-cc44-c2bd-2851-dc977c1ec74f@symas.com> Date: Wed, 28 Oct 2020 14:35:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_RED, WEBMAIL_BODY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:35:56 -0000 Peter Smith via Binutils wrote: > Apologies in advance if the webmail client mangles the response or threading. > > Just wanted to add to MaskRay's concerns about what the semantics are for a linker. > * Where are the static library dependencies placed in the order of input files? Immediately after the static library seems the most logical choice although this will make it harder for users to interpose objects/libraries to override choices. One major advantage of this approach is that if an end user needs to make changes, they can easily do so without requiring the original source code or a compiler. > * What happens when there are cyclic dependencies between libraries? Would the user be expected to know to wrap an individual library in a start-group end-group? Should the linker implicitly add start-group end-group around the dependencies? I don't see how this is relevant. Circular dependencies would be a problem and would require the same solution regardless. > * This does seem like it will work for libraries designed to be incorporated as a whole (like a dynamic library), but it seems like it could have awkward corner cases. > > Although not fundamentally opposed to this; personally I'm not a fan of encoding dependencies for static libraries. I see these more of a collection of objects and not a single entity like a dynamic library. If static libraries are being used whole, one way of implementing this would be to add a member to the library that is just a linker script with INPUT and GROUP commands, and link using --whole-archive. If you're making a lot of use of --whole-archive You're Doing It Wrong. Should just use "ld -r -o aggregate.o foo.o bar.o ..." and save the linker trouble later. Though this raises an interesting point, why not just eliminate the distinction between libraries and individual .o files, like the AIX linker does? I.e., the AIX linker is capable of extracting individual required symbols from a .o file, instead of just linking the entire thing as a unit. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/