From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62485 invoked by alias); 11 May 2017 14:46:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 62392 invoked by uid 89); 11 May 2017 14:46:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=meet X-HELO: mailbackend.panix.com X-Gm-Message-State: AODbwcAnaxXxXXq7mFWfbUu8fsaR/yIBA8YlR2IEu5LvGRf8voJrvGAb F6AVqjktAOnsQezFqp2WpvbyCKgZlw== X-Received: by 10.36.7.3 with SMTP id f3mr1380262itf.27.1494513966412; Thu, 11 May 2017 07:46:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170509154103.11973-1-zackw@panix.com> <20170509154103.11973-6-zackw@panix.com> <9d81a666-ecd7-578e-3475-9f3922619980@redhat.com> <7401509c-93fd-f1da-abe8-d0e6a844e886@redhat.com> From: Zack Weinberg Date: Thu, 11 May 2017 14:46:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/10] Remove __need macros from errno.h (__need_Emath, __need_error_t). To: Joseph Myers Cc: Florian Weimer , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-05/txt/msg00304.txt.bz2 On Thu, May 11, 2017 at 10:30 AM, Joseph Myers 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 > , 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