Re: [PATCH 05/10] Remove __need macros from errno.h (__need_Emath, __need_error_t).

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 11 May 2017, Zack Weinberg wrote:

> On Wed, May 10, 2017 at 8:03 AM, Florian Weimer <fweimer@redhat.com> wrote:
> > However, I still think that the NaCl port should be aligned with the rest of
> > glibc in this regard, and that Zack's cleanup should not introduce a new
> > extension point for it.  Particularly since we don't have a working port
> > right now which would exercise this functionality, so it's likely to be
> > broken anyway.
> 
> What would you have me do with sysdeps/nacl/errnos.awk, then?
> 
> (If the NaCl port doesn't work, should we just discard it altogether?
> I see value in keeping a non-Linux port around, but there are rumors
> to the effect that Google has abandoned NaCl[1] so maybe not _this_
> one...)

Well, we need such a port that works in current glibc sources (used 
together with upstream sources of other toolchain components), and where 
build-many-glibcs.py knows how and where to check out any OS-specific 
components (analogous to Linux kernel headers, for example) needed and how 
to build a cross toolchain for that target.  Neither NaCl nor Hurd meets 
those criteria at present; either could be made to meet them, if someone 
sufficiently familiar with building toolchains and glibc for that OS does 
the work required.

Otherwise, I'm not sure if anyone is currently working on the GNU/kFreeBSD 
port of glibc, but it's not upstream.  (And as a system with Unix-like 
syscalls, it would be less different from the Linux ports than NaCl or 
Hurd.)  And there's the WebAssembly port 
<https://github.com/pipcet/glibc>, also not (yet) upstream (neither is the 
GCC port, though at least some binutils support is upstream).

-- 
Joseph S. Myers
joseph@codesourcery.com