From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 805C4386F437 for ; Sun, 3 May 2020 20:31:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 805C4386F437 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jVLGV-0004Eb-3X; Sun, 03 May 2020 20:31:07 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jVLGN-0000p2-S2; Sun, 03 May 2020 22:30:59 +0200 From: Florian Weimer To: Fangrui Song via Libc-alpha Cc: Fangrui Song Subject: Re: [PATCH] install: Delete scripts/output-format.sed and support lld References: <20200411232340.135070-1-maskray@google.com> Date: Sun, 03 May 2020 22:30:59 +0200 In-Reply-To: <20200411232340.135070-1-maskray@google.com> (Fangrui Song via Libc-alpha's message of "Sat, 11 Apr 2020 16:23:40 -0700") Message-ID: <87h7wwiwvw.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 20:31:09 -0000 * Fangrui Song via Libc-alpha: > GNU ld and gold can skip a script with incompatible OUTPUT_FORMAT and > find the next script in the search path. So libc.so linked with lld > cannot be skipped automatically. However, this is considered a minor > functionality loss by lld maintainers. That completely depends on how typical installations set up their linker search paths. Figuring that out is likely more work than providing the correct OUTPUT_FORMAT information in the linker script, so I'm not sure if the patch goes in the right direction. In any case, the choice of linker for building glibc should result in as little semantic difference in the produced artifacts, to avoid inflating the compatibility matrix. If OUTPUT_FORMAT is indeed unnecessary (based on the evaluation I mentioned), it should be removed unconditionally. But as I said, it's probably better to find an alternative way to generate the right OUTPUT_FORMAT directive for the linker script.