From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D942F385B504 for ; Wed, 21 Dec 2022 08:24:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D942F385B504 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671611052; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=sdKnihtL1qaQC7krJYKdQO2gMytQ6QnG4fgxiKBObUo=; b=HOZpeqTr7Sl8t4vESjA2uRsUKk7UPBy/eNez/6TNP5mqZeSg1LjKpc+NfljYNNjoYMhCib TeM9r56kr3kXitb2PqTiLKMjj0jXRH0U3uq+Q2GzAur+R1xabi730g3SC3oH32lZ0nWg4S sQKNd9YfXZfcHlyUjB6/Z+vznUwTpvg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-597-QC_eKNesPAqc0wF3AoAMWg-1; Wed, 21 Dec 2022 03:24:09 -0500 X-MC-Unique: QC_eKNesPAqc0wF3AoAMWg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DB1A780234E; Wed, 21 Dec 2022 08:24:08 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.193.230]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6FCB14152F4; Wed, 21 Dec 2022 08:24:08 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 38760A80742; Wed, 21 Dec 2022 09:24:07 +0100 (CET) Date: Wed, 21 Dec 2022 09:24:07 +0100 From: Corinna Vinschen To: Mike Frysinger Cc: Richard Earnshaw , newlib@sourceware.org Subject: Re: [PATCH] libgloss: arm: break newlib dependency Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Mike Frysinger , Richard Earnshaw , newlib@sourceware.org References: <20221214091304.25170-1-vapier@gentoo.org> <7ca62fc8-618e-e213-92c1-195a9b55da1c@foss.arm.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 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. > -mike 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. Corinna