This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Upstreaming the glibc Hurd port


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]