bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upstreaming the glibc Hurd port


From: Joseph Myers
Subject: Re: Upstreaming the glibc Hurd port
Date: Fri, 19 Jan 2018 15:11:51 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Fri, 19 Jan 2018, Thomas Schwinge wrote:

> Hi!
> 
> On Fri, 19 Jan 2018 13:08:01 +0000, Joseph Myers <joseph@codesourcery.com> 
> wrote:
> > On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > > [build-many-glibcs.py]
> 
> > Do you have advice on versions to use of mig / gnumach / hurd?
> > 
> > Currently, build-many-glibcs.py uses (by default) release versions of most 
> > components other than glibc itself, release branches for gcc / binutils.  
> > Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd 
> > be used for building current glibc for Hurd, or is it preferable or 
> > necessary to use newer development versions of those components?
> 
> The current releases should generally be fine, yes.

The source file sysdeps/mach/hurd/bits/errno.h is generated from sources 
including some headers from those components.  I don't know how often 
those may change in ways that affect that header, or what versions the 
current header corresponds to, but in any case it's a known issue that 
there are several generated files in the source tree that 
build-many-glibcs.py doesn't yet touch on checkout.

> (This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
> libpthread releases, but no need for you to wait for these, as far as I
> know.)

Regarding libpthread, I don't propose build-many-glibcs.py support for a 
separate libpthread component; what's relevant is whatever version goes on 
the sthibaul/hurd-builds branch of glibc (set up to build without the old 
add-ons mechanism), and in due course on master.

-- 
Joseph S. Myers
joseph@codesourcery.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]