From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-042.btinternet.com (mailomta28-sa.btinternet.com [213.120.69.34]) by sourceware.org (Postfix) with ESMTPS id ECF6D3836423 for ; Tue, 22 Feb 2022 12:35:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ECF6D3836423 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.38.4]) by sa-prd-fep-042.btinternet.com with ESMTP id <20220222123532.NETE30440.sa-prd-fep-042.btinternet.com@sa-prd-rgout-001.btmx-prd.synchronoss.net> for ; Tue, 22 Feb 2022 12:35:32 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613006A9179B747D X-Originating-IP: [86.139.167.74] X-OWM-Source-IP: 86.139.167.74 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrkeekgdefgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeffkeeigfdujeehteduiefgjeeltdelgeelteekudetfedtffefhfeufefgueettdenucfkphepkeeirddufeelrdduieejrdejgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtfegnpdhinhgvthepkeeirddufeelrdduieejrdejgedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedupdhrtghpthhtohepnhgvfihlihgssehsohhurhgtvgifrghrvgdrohhrgh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (86.139.167.74) by sa-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613006A9179B747D for newlib@sourceware.org; Tue, 22 Feb 2022 12:35:32 +0000 Message-ID: Date: Tue, 22 Feb 2022 12:34:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH v2] newlib: libm: workaround ar duplicate member behavior Content-Language: en-GB To: "newlib@sourceware.org" References: <20220221204327.2945-1-vapier@gentoo.org> <20220222002114.10214-1-vapier@gentoo.org> From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.8 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 12:35:35 -0000 On 22/02/2022 11:31, Corinna Vinschen wrote: > On Feb 21 19:21, Mike Frysinger wrote: >> GNU ar has undocumented behavior where it doesn't dedupe its inputs if >> they're all on the same command line, so we have to dedupe ourselves. >> --- >> v2 >> - use awk to dedupe the object list I think this could still at least use a comment about how the ordering of the inputs relates to which duplicate object are dropped and which are kept. (I'm assuming cpu-specific ones are meant to be kept in preference to generic routines, but how does this achieve that?) > This seems to work. > > However, what do we have to do in future to make sure the order is > always correct? > > And the heritic question: Wouldn't it be safer to keep the old > per-subdir lib.a logic? Considering the problem in the next larger context: why are we doing this at all? Is this just so the generic fenv routines are chewed on as they contain the doc markup? In which case it would be simpler to do that explicitly. If it's so that a cpu- specific fenv doesn't need to provide all the objects, well, that could be done explicitly as well, I think?