public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>, newlib@sourceware.org
Subject: Re: [PATCH] libgloss: arm: break newlib dependency
Date: Wed, 21 Dec 2022 09:24:07 +0100	[thread overview]
Message-ID: <Y6LCp1codfNtRrO6@calimero.vinschen.de> (raw)
In-Reply-To: <Y6JlydSTs3vWtnix@vapier>

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 <toplevel>/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


  reply	other threads:[~2022-12-21  8:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14  9:13 Mike Frysinger
2022-12-19  9:34 ` Corinna Vinschen
2022-12-19 10:08 ` Richard Earnshaw
2022-12-21  1:47   ` Mike Frysinger
2022-12-21  8:24     ` Corinna Vinschen [this message]
2022-12-22 22:03       ` Mike Frysinger
2023-01-03 14:56         ` Richard Earnshaw
2023-01-04  2:04 ` Mike Frysinger
2023-01-04  2:17   ` Stefan Tauner
2023-01-04  3:06     ` Mike Frysinger
2023-01-09 10:29       ` Corinna Vinschen
2023-01-10  2:07         ` Mike Frysinger
2023-01-10  8:43           ` Corinna Vinschen
2023-01-11  6:01 ` [PATCH v3] " Mike Frysinger
2023-01-11  9:14   ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y6LCp1codfNtRrO6@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=newlib@sourceware.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).