This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 05/10] Remove __need macros from errno.h (__need_Emath, __need_error_t).
On Thu, May 11, 2017 at 10:30 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 11 May 2017, Zack Weinberg wrote:
>>
>> 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).
None of that answers the immediate question, which is, given that the
NaCl port *currently in glibc* can't be built by build-many-glibcs and
is said to be at least somewhat broken, should it be deleted?
zw