[PATCH] libgloss: arm: break newlib dependency

Corinna Vinschen vinschen@redhat.com
Wed Dec 21 08:24:07 GMT 2022

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.


More information about the Newlib mailing list