From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 0A0713858D1E for ; Tue, 3 Jan 2023 14:56:18 +0000 (GMT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7B1A91516; Tue, 3 Jan 2023 06:56:59 -0800 (PST) Received: from [10.2.78.76] (unknown [10.2.78.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5C7B63F587; Tue, 3 Jan 2023 06:56:17 -0800 (PST) Message-ID: Date: Tue, 3 Jan 2023 14:56:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] libgloss: arm: break newlib dependency Content-Language: en-GB To: Mike Frysinger , newlib@sourceware.org References: <20221214091304.25170-1-vapier@gentoo.org> <7ca62fc8-618e-e213-92c1-195a9b55da1c@foss.arm.com> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 22/12/2022 22:03, Mike Frysinger wrote: > On 21 Dec 2022 09:24, Corinna Vinschen wrote: >> On Dec 20 20:47, Mike Frysinger wrote: >>> On 19 Dec 2022 10:08, Richard Earnshaw wrote: >>>> On 14/12/2022 09:13, Mike Frysinger wrote: >>>>> The libgloss port has been reaching back into newlib internals for a >>>>> single header whose contents have been frozen for almost a decade. >>>>> To break this backwards libgloss->newlib dependency, duplicate that >>>>> header here so we can keep libgloss independent as it's meant to be. >>>> >>>> This isn't really 'newlib internals', it's a header file that tries to >>>> provide ACLE[1] compatibility for older versions of GCC that lacked such >>>> support. Having two copies of this is a maintenance burden, so I'm not >>>> entirely sure this is a great thing to do, even if the copies are >>>> supposed to be identical. >>> >>> newlib already has 2 itself. so this will be a 3rd. i don't disagree with >>> the maintenance concern, but the fact the file hasn't changed in a decade, >>> and seems unlikely to ever change, makes me not worry about it. >>> >>>> If we can agree on a common location in the source tree that both newlib >>>> and libgloss can pull this from, then I'm happy to move it if that would >>>> make you happier. >>> >>> libgloss is supposed to be C library agnostic. the C library (newlib) itself >>> relies on the output of libgloss (e.g. the crt and low level syscalls). since >>> there is no other tree/project in play that i'm aware of, that means there are >>> really only three options: >>> * have the compiler provide it >>> * have libgloss provide it (and newlib uses that) >>> * duplicate the header >>> >>> i know the libgloss/newlib separation is still pretty unclean due to the two >>> projects historically being one (i.e. everything in newlib), but i don't think >>> that's a good reason to keep it messy with libgloss depending on newlib. >> >> Why not just /include then? It already contains target-specific >> stuff in the opcodes subdir, or the xtensa headers. Having to share them >> between newlib and libgloss should be reason enough to move the file there. > > the file is currently installed under machine/. none of the installed headers > use it though, so maybe it doesn't really need to be installed. if that's the > case, moving it into the top-level include/ would work. > -mike The file should not be installed, it's only for the build system. If it is being installed, then that's a bug. Moving it to /include is ok by me. We'll need to sync it to the binutils repo (to support all-in-one build trees), but that's not a real issue as the file doesn't change often as you've already noted. R.