Sorry for the delay!
Manolis Ragkousis <manolis...@gmail.com> 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 @@
>>>>> ++@end 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’.
