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: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 12 Sep 2017 18:51:08 -0300
- 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>
On 12/09/2017 17:36, Samuel Thibault wrote:
> Adhemerval Zanella, on mar. 12 sept. 2017 17:34:51 -0300, wrote:
>> Samuel, since you spent time in a lot of patches to fix Hurd build,
>> wouldn't be better if you could add hurd build support on
>> build-many-glibcs.py?
>
> Unfortunately, we are still far from having something buildable. I'm
> here just keeping up with the newer versions, but there are patches
> needed (e.g. for TLS) which are not included yet and need care.
So currently you can't really build glibc master for hurd, is it
correct?
>
>> I do not know if it is possible to cross-compiling hurd on Linux,
>
> It is, but that needs a cross-toolchain which is really not trivial :)
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?
>
>> but I think at least a native build could be useful so generic changes
>> could be checked against Hurd as well.
>
> Yep, ideally :)
>
> Samuel
>
PS: I am CC'ing libc-alpha because it was my initial intent.