unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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’.

  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).