This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [hurd,commited] hurd: Fix build without NO_HIDDEN
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Samuel Thibault <samuel dot thibault at ens-lyon dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 12 Sep 2017 23:14:54 +0000
- Subject: Re: [hurd,commited] hurd: Fix build without NO_HIDDEN
- Authentication-results: sourceware.org; auth=none
- References: <20170911233614.26389-1-samuel.thibault@ens-lyon.org> <b8150e05-2d78-ca6f-fcf4-667f1f390485@linaro.org> <20170912203634.c7qp4pcgeaawekhh@var.youpi.perso.aquilenet.fr> <20cd52f7-eb01-2712-5909-1d724a874535@linaro.org>
On Tue, 12 Sep 2017, Adhemerval Zanella wrote:
> Right, but how currently are you actually testing your changes? Do we
> need an old dated toolchain? If so, is there any option to actually
> integrate it on build-many-glibcs.py?
https://www.gnu.org/software/hurd/toolchain/cross-gnu.html describes a
script for building a cross toolchain for Hurd. I don't know how current
it is.
Yes, we should have such support in build-many-glibcs.py for checking out
and building whatever's relevant from MIG / GNU Mach / Hurd / Hurd
libpthread and building glibc for Hurd. I think that makes sense even
without functional Hurd support in glibc; it will just fail in all builds
(like existing broken configurations) and then once the Hurd support in
glibc is fixed, we'll see it change from FAIL to PASS in the results from
the bots.
(Should Hurd libpthread actually be part of glibc rather than a separate
package?)
--
Joseph S. Myers
joseph@codesourcery.com