From: ludo@gnu.org (Ludovic Courtès)
To: Manolis Ragkousis <manolis837@gmail.com>
Cc: Guix-devel@gnu.org
Subject: Re: [PATCH] gnu: base: Add Glibc-Hurd.
Date: Sat, 21 Jun 2014 17:20:24 +0200 [thread overview]
Message-ID: <878uoqguh3.fsf@gnu.org> (raw)
In-Reply-To: <CAFtzXzMBfcemYpb=+_RcGNyPDyV5haUJ6W3TxpVpqRN0Gi6j8g@mail.gmail.com> (Manolis Ragkousis's message of "Wed, 18 Jun 2014 19:56:49 +0000")
Sorry for the delay!
Manolis Ragkousis <manolis837@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’.
next prev parent reply other threads:[~2014-06-21 15:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 21:09 [PATCH] gnu: base: Add Glibc-Hurd Manolis Ragkousis
2014-06-02 21:38 ` Ludovic Courtès
2014-06-06 22:23 ` Manolis Ragkousis
2014-06-09 19:27 ` Ludovic Courtès
2014-06-18 19:56 ` Manolis Ragkousis
2014-06-21 15:20 ` Ludovic Courtès [this message]
2014-07-17 15:39 ` Manolis Ragkousis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878uoqguh3.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=Guix-devel@gnu.org \
--cc=manolis837@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).