This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Which subdirectories need to support !_LIBC?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Will Newton <will dot newton at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 26 Feb 2015 14:56:47 +0000
- Subject: Re: Which subdirectories need to support !_LIBC?
- Authentication-results: sourceware.org; auth=none
- References: <54EDD1EB dot 3030008 at redhat dot com> <CAFbHwiQi1u1QPz7HPde4GoDcOMZx-hV1rubh66UFemJxxmqk-g at mail dot gmail dot com> <54EF328D dot 4050207 at redhat dot com>
On Thu, 26 Feb 2015, Florian Weimer wrote:
> On 02/25/2015 02:47 PM, Will Newton wrote:
> > On Wed, Feb 25, 2015 at 1:45 PM, Florian Weimer <fweimer@redhat.com> wrote:
> >> Are there any subdirectories which need to be built externally except
> >> intl and soft-fp?
> >
> > This list may be helpful:
> >
> > https://sourceware.org/glibc/wiki/SharedSourceFiles
>
> Hmm. I noticed that while working on posix/glob.c. It's diverged a bit
> from gnulib, and our changes use glibc-specific things outside of _LIBC
> defines.
>
> I wonder what the proper way forward is here. Certainly it does not
> make sense to have AmgiaOS support in a glibc-specific source file.
Except for licenses and for gnulib's avoidance of TABs in some places,
changes to shared files should typically be merged in both directions
(with any necessary conditionals introduced) until those are the only
differences between the two places. Changes from gnulib do need
submitting to glibc as individual logical changes and reviewing as usual,
but if the change only relates to portability / cases not used in glibc,
the review can be only for coding style issues rather than substance.
--
Joseph S. Myers
joseph@codesourcery.com