guix-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] gnu: base: Add Glibc-Hurd.


From: Ludovic Courtès
Subject: Re: [PATCH] gnu: base: Add Glibc-Hurd.
Date: Sat, 21 Jun 2014 17:20:24 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

Sorry for the delay!

Manolis Ragkousis <address@hidden> 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’s build system normally.  Could you check what’s going on?
>
> Normally before building glibc, we should first do make
> install-headers for libpthread.

I don’t think so.  Given that libpthread is a libc add-on, its headers
should be picked automatically.  We should check with bug-hurd people,
and keep what you’ve 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 @@
>>>>> address@hidden deftypefun
>>>>> + @node Contributors, Free Manuals, Platform, Top
>>>>> + @c %MENU% Who wrote what parts of the GNU C Library
>>>>> + @appendix Contributors to @theglibc{}
>>>>
>>>> What’s 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 ‘texinfo-4’ instead of
>> ‘texinfo’, which would be easier.  Could you check that?
> still the same, added explanation.

It’s very surprising that the manual doesn’t build, not even 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’s thread_info type and nscd’s.  I’ve just emailed
bug-hurd.

The patch itself looks good to me!  Some mostly cosmetic comments:

@@ -302,6 +302,8 @@ dist_patch_DATA =                                           
\
   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’s going on, possibly
with links to discussions on the subject.

+There is no definition for  __thread_terminate_release yet, so according to 
Samuel we disable it.

Same, better explain why __thread_terminate_release is missing, why it’s
OK to remove that call, with a link to the discussion.

+__SPIN_LOCK_INITIALIZER gets defined to zero so we can start using libpthread.

Same here.

These are all small changes, but I think it’s important to keep track of
why all these things are done this way, because it’s not trivial.

Thank you!

Ludo’.



reply via email to

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