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: Thu, 25 Jan 2018 15:43:37 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Thu, 25 Jan 2018, Samuel Thibault wrote:

> Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote:
> > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote:
> > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote:
> > > > and indicate whether the above errors indicate problems with these
> > > > changes, or simply incompleteness of the build support on the
> > > > sthibaul/hurd-builds branch at present?
> > > 
> > > They are not related to the changes.  I have pushed fix updates against
> > > them.
> > 
> > The next error is about inclusion of libc-lockP.h.  That's where I'll
> > have to import libpthread.
> 
> Which I have now done.  I see that it now fails on missing reference to
> __file_exec_paths.  That's indeed a new RPC which hasn't been released
> yet, so we'd need to use a git snapshot.

If a git version of Hurd (or some other component) is needed, it would be 
reasonable to make vcs-mainline the default version of Hurd until there's 
a new release.  Longer-term (once Hurd is working on master) I'd hope 
there would be a clear (and documented) notion of minimum compile-time and 
run-time Hurd versions, as there is for glibc using the Linux kernel, with 
any features of newer versions being used only conditionally, so that the 
most recent releases are generally sufficient to build and use glibc for 
Hurd.

-- 
Joseph S. Myers
joseph@codesourcery.com



reply via email to

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