From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] gnu: base: Add Glibc-Hurd. Date: Sat, 21 Jun 2014 17:20:24 +0200 Message-ID: <878uoqguh3.fsf@gnu.org> References: <874n03gfg1.fsf@gnu.org> <871tux994j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyN5p-00054s-Ie for Guix-devel@gnu.org; Sat, 21 Jun 2014 11:20:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WyN5f-0003Nh-US for Guix-devel@gnu.org; Sat, 21 Jun 2014 11:20:37 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:34458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyN5f-0003NQ-En for Guix-devel@gnu.org; Sat, 21 Jun 2014 11:20:27 -0400 In-Reply-To: (Manolis Ragkousis's message of "Wed, 18 Jun 2014 19:56:49 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Manolis Ragkousis Cc: Guix-devel@gnu.org Sorry for the delay! Manolis Ragkousis skribis: [...] >>>> However, why do the headers need to be copied in the first place? I >>>> believe the sysdeps headers of add-ons are automatically picked up the >>>> libc=E2=80=99s build system normally. Could you check what=E2=80=99s = going on? > > Normally before building glibc, we should first do make > install-headers for libpthread. I don=E2=80=99t think so. Given that libpthread is a libc add-on, its head= ers should be picked automatically. We should check with bug-hurd people, and keep what you=E2=80=99ve done in the meantime. >>>>> --- /dev/null >>>>> +++ b/gnu/packages/patches/glibc-manual-fix.patch >>>>> @@ -0,0 +1,12 @@ >>>>> +diff --git a/manual/contrib.texi b/manual/contrib.texi >>>>> +index 3b9d23c..376b40d 100644 >>>>> +--- a/manual/contrib.texi >>>>> ++++ b/manual/contrib.texi >>>>> +@@ -1,3 +1,4 @@ >>>>> ++@end deftypefun >>>>> + @node Contributors, Free Manuals, Platform, Top >>>>> + @c %MENU% Who wrote what parts of the GNU C Library >>>>> + @appendix Contributors to @theglibc{} >>>> >>>> What=E2=80=99s this? (Missing explanation.) >>> >>> Without this, I get the error >>>> ./contrib.texi:1: @node seen before @end deftypefun >> >> I suppose you could do without the patch by using =E2=80=98texinfo-4=E2= =80=99 instead of >> =E2=80=98texinfo=E2=80=99, which would be easier. Could you check that? > still the same, added explanation. It=E2=80=99s very surprising that the manual doesn=E2=80=99t build, not eve= n with Texinfo 4. > In the last patch I forgot to send the libpthread-glibc-preparation > patch, which I added now. > > In the glibc-fix.patch I remove #define _EXTERN_INLINE because it > doesn't get defined as it should. I onced asked about it in bug-hurd, > but I forgot about that. I am looking into it now. Regarding nscd, the build log you posted shows that the problem is a conflict between Mach=E2=80=99s thread_info type and nscd=E2=80=99s. I=E2= =80=99ve just emailed bug-hurd. The patch itself looks good to me! Some mostly cosmetic comments: @@ -302,6 +302,8 @@ dist_patch_DATA =3D \ gnu/packages/patches/glib-tests-prlimit.patch \ gnu/packages/patches/glibc-bootstrap-system.patch \ gnu/packages/patches/glibc-ldd-x86_64.patch \ + gnu/packages/patches/glibc-make-4.0.patch \ + gnu/packages/patches/glibc-fix.patch \ Please call the latter glibc-hurd-extern-inline.patch, for instance. --- /dev/null +++ b/gnu/packages/patches/glibc-fix.patch @@ -0,0 +1,29 @@ This patch misses a one-line explanation of what it does. --- /dev/null +++ b/gnu/packages/patches/libpthread-glibc-preparation.patch @@ -0,0 +1,51 @@ +This will allow libpthread to be build as an addon. Likewise, please add a sentence explaining what=E2=80=99s going on, possibly with links to discussions on the subject. +There is no definition for __thread_terminate_release yet, so according t= o Samuel we disable it. Same, better explain why __thread_terminate_release is missing, why it=E2= =80=99s OK to remove that call, with a link to the discussion. +__SPIN_LOCK_INITIALIZER gets defined to zero so we can start using libpthr= ead. Same here. These are all small changes, but I think it=E2=80=99s important to keep tra= ck of why all these things are done this way, because it=E2=80=99s not trivial. Thank you! Ludo=E2=80=99.