Re: [PATCH] gnu: base: Add glibc-hurd and hurd-minimal.
Done and pushed. Manolis
Re: [PATCH] gnu: base: Add glibc-hurd and hurd-minimal.
Manolis Ragkousis manolis...@gmail.com skribis: From c64bb1c8c91b8f50d2955f5ae3bd1c8735ff40d9 Mon Sep 17 00:00:00 2001 From: Manolis Ragkousis manolis...@gmail.com Date: Sat, 27 Sep 2014 20:07:19 +0300 Subject: [PATCH] gnu: base: Add glibc-hurd and hurd-minimal. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * gnu/packages/base.scm (glibc/hurd, glibc/hurd-headers): New variables. * gnu/packages/hurd.scm (hurd-minimal): New variable. * gnu/packages/patches/glibc-hurd-extern-inline.patch: New file. * gnu/packages/patches/libpthread-glibc-preparation.patch: New file. * gnu-system.am (dist_patch_DATA): Add them. Co-authored-by: Ludovic Courtès l...@gnu.org Co-authored-by: Mark H Weaver m...@netris.org [...] + ac_cv_search_clnt_create=no) Could you add the rationale as a comment just above (“Skip the clnt_create check because ...”)? + This package provides libihash, needed to build the GNU C +Library for GNU/Hurd) Missing period. OK to commit to wip-hurd with these changes, thank you! Ludo’.
Re: [PATCH] gnu: base: Add Glibc-Hurd Headers.
Manolis Ragkousis manolis...@gmail.com skribis: Taken care of the FIXME. Thanks, I’ve merged it with the other commit on wip-hurd, and rebased it on top of master. Just wanted to add that in base.scm, instead of gnu-gettext we needed perl. Probably I changed it by mistake while rebasing some local commits. OK. And thread_terminate does exist, that's why it's enough for our needs. You mean ‘thread_terminate_release’? The comment in libpthread-glibc-preparation.patch still reads: --8---cut here---start-8--- We are using a version of GNU Mach that lacks 'thread_terminate_release' (not introduced yet). The 'thread_terminate' RPC call will be enough for our needs. See http://lists.gnu.org/archive/html/bug-hurd/2014-05/msg00127.html. --8---cut here---end---8--- Ludo’.
Re: [PATCH] gnu: base: Add Glibc-Hurd Headers.
And thread_terminate does exist, that's why it's enough for our needs. You mean ‘thread_terminate_release’? Okay, let me explain it a bit better Here is the part we are interested in libpthread/sysdeps/mach/pt-thread-terminate.c /* Terminate and release all that's left. */ err = __thread_terminate_release (kernel_thread, mach_task_self (), kernel_thread, reply_port, stackaddr, stacksize); /* The kernel does not support it yet. Leak but at least terminate correctly. */ err = __thread_terminate (kernel_thread); The comment The kernel does not support it yet. is misleading. It wants to say that __thread_terminate_release is not yet supported so __thread_terminate can be used instead, to at least terminate it correctly, even though we will have leaks. That's why Samuel told me here http://lists.gnu.org/archive/html/bug-hurd/2014-05/msg00127.html Manolis Ragkousis, le Thu 15 May 2014 21:08:41 +, a écrit : So I commented the part that calls this function out and glibc gets built succefully with libpthread. err = __thread_terminate_release (kernel_thread, mach_task_self (), That should be fine, yes, IIRC I left a thread_terminate call just below, which should work enough for your needs. Manolis
Re: [PATCH] gnu: base: Add Glibc-Hurd Headers.
Hi, Manolis! I have finally reviewed the 2 pending patches of yours that add glibc-hurd and glibc-hurd-headers. I’ve combined these 2 patches as well as the hurd-minimal one into a single one to make a self-contained patch. I’ve then reviewed it, which led me to simplify a few things, and add a bunch of FIXMEs, and pushed the result as the ‘wip-hurd’ branch. Can you please check it out, look at all the FIXMEs, both in the .scm and .patch files, address them, and post a patch here (no need for a detailed commit log.) The FIXMEs are about: • Things that are probably unneeded: if there are actually unneeded, please remove them, otherwise add a comment clearly stating why they are needed. • Workarounds that lack a justification, have an unclear justification, and/or lack a link to the relevant mailing list discussion. If there is any FIXME that is unclear to you, please do let me know. There are many workarounds being applied here, so it’s very important to be rigorous in defining what they’re for so this can be maintained. Also make sure that the result does not introduce any regressions with the not-yet-reviewed cross-base.scm patch. I think we’re on the right track now. :-) Thanks in advance, and again apologies for the long delay! Ludo’.
Re: [PATCH] gnu: base: Add Glibc-Hurd.
Sorry for the delay, (damn greek summer temperatures) here is the updated patch. I added explanations to all the patches as you told me, so to be better understood why I did what I did. Thanks, Manolis From 9195c2d57bc0e3aad2a4beb6806ba8d6be8b33e4 Mon Sep 17 00:00:00 2001 From: Manolis Ragkousis manolis...@gmail.com Date: Thu, 17 Jul 2014 18:26:27 + Subject: [PATCH] gnu: base: Add Glibc-Hurd. * gnu/packages/base.scm (glibc/hurd): New variable. * gnu/packages/patches/glibc-make-4.0.patch: New patch. * gnu/packages/patches/glibc-hurd-extern-inline.patch: New patch. * gnu/packages/patches/libpthread-glibc-preparation.patch: New patch. * gnu-system.am (dist_patch_DATA): Add it. --- gnu-system.am | 3 + gnu/packages/base.scm | 69 ++ .../patches/glibc-hurd-extern-inline.patch | 34 +++ gnu/packages/patches/glibc-make-4.0.patch | 12 .../patches/libpthread-glibc-preparation.patch | 58 ++ 5 files changed, 176 insertions(+) create mode 100644 gnu/packages/patches/glibc-hurd-extern-inline.patch create mode 100644 gnu/packages/patches/glibc-make-4.0.patch create mode 100644 gnu/packages/patches/libpthread-glibc-preparation.patch diff --git a/gnu-system.am b/gnu-system.am index 7d2fbcc..6e26693 100644 --- a/gnu-system.am +++ b/gnu-system.am @@ -307,6 +307,8 @@ dist_patch_DATA = \ gnu/packages/patches/glib-tests-timer.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-hurd-extern-inline.patch \ gnu/packages/patches/gnunet-fix-scheduler.patch \ gnu/packages/patches/gnunet-fix-tests.patch \ gnu/packages/patches/gobject-introspection-cc.patch \ @@ -333,6 +335,7 @@ dist_patch_DATA = \ gnu/packages/patches/libtool-skip-tests.patch \ gnu/packages/patches/libtool-skip-tests-for-mips.patch \ gnu/packages/patches/libssh-CVE-2014-0017.patch \ + gnu/packages/patches/libpthread-glibc-preparation.patch \ gnu/packages/patches/luit-posix.patch\ gnu/packages/patches/m4-gets-undeclared.patch \ gnu/packages/patches/m4-readlink-EINVAL.patch \ diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm index c280cff..2166a77 100644 --- a/gnu/packages/base.scm +++ b/gnu/packages/base.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2014 Andreas Enge andr...@enge.fr ;;; Copyright © 2012 Nikita Karetnikov nik...@karetnikov.org ;;; Copyright © 2014 Mark H Weaver m...@netris.org +;;; Copyright © 2014 Manolis Fragkiskos Ragkousis manolis...@gmail.com ;;; ;;; This file is part of GNU Guix. ;;; @@ -35,6 +36,9 @@ #:use-module (gnu packages linux) #:use-module (gnu packages texinfo) #:use-module (gnu packages pkg-config) + #:use-module (gnu packages gettext) + #:use-module (gnu packages hurd) + #:use-module (guix git-download) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) @@ -512,6 +516,71 @@ with the Linux kernel.) (license lgpl2.0+) (home-page http://www.gnu.org/software/libc/;))) +(define-public glibc/hurd + (package (inherit glibc) +(name glibc-hurd) +(version 2.18) +(source + (origin + (method git-fetch) + (uri (git-reference + (url git://git.sv.gnu.org/hurd/glibc) + (commit a9d8d3808f18de4da9b587e9bdfb6cca4704344b))) + (sha256 +(base32 + 0jmczzdyps5syhrqyf7lgl3h77br8s74qw0417jp8b4f29ks7pbz)) + (file-name (string-append name - version)) + (patches (list (search-patch glibc-make-4.0.patch) + (search-patch glibc-hurd-extern-inline.patch) + +;; Libc provides hurd.h, which includes a bunch of Hurd and Mach headers, +;; so both should be propagated. +(propagated-inputs `((gnumach-headers ,gnumach-headers) + (hurd-headers ,hurd-headers) + (hurd-minimal ,hurd-minimal))) +(native-inputs + `((patch/libpthread-patch ,(search-patch libpthread-glibc-preparation.patch)) + (mig ,mig) + (perl ,perl) + (texinfo,texinfo) + (gettext ,gnu-gettext) + (libpthread ,(origin +(method git-fetch) +(uri (git-reference + (url git://git.sv.gnu.org/hurd/libpthread) + (commit f517024dce3e21c525a7b634eab61302d6b99150))) +(sha256 + (base32 + 0yqfm1hfqlyjzqv3mgf9a3mh4qxx1mqkzn5xiac2vlvji8nns35y)) +(file-name libpthread ) + +(arguments + (substitute-keyword-arguments (package-arguments glibc) + ((#:configure-flags cf) +`(append (list --host=i686-pc-gnu + ;; Since Hurd supports only i686 +
Re: [PATCH] gnu: base: Add Glibc-Hurd.
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’.
Re: [PATCH] gnu: base: Add Glibc-Hurd.
Γειά σας!
Manolis Ragkousis manolis...@gmail.com skribis:
+(propagated-inputs `((gnumach-headers ,gnumach-headers)
+ (hurd-headers ,hurd-headers)
+ (hurd-minimal ,hurd-minimal)))
Add a one-line comment saying why they’re propagated.
Actually I am not sure, should they be propagated?
Libc provides hurd.h, which includes a bunch of Hurd and Mach headers,
so both should be propagated.
Can you add this explanation in a comment above ‘propagated-inputs’?
[...]
Is --host the only thing that differs from ‘glibc’? If so, we need to
factorize things.
In order for glibc/hurd to build, we need to remove
(string-append --with-headers=
(assoc-ref %build-inputs linux-headers)
/include)
--enable-kernel=2.6.30
;; XXX: Work around undefined reference to `__stack_chk_guard'.
libc_cv_ssp=no
which are linux specific, and add
--host=i686-pc-gnu
--disable-profile
--disable-multi-arch
--disable-nscd
--enable-obsolete-rpc
How do you suggest doing it? :-)
Something like:
(define glibc-hurd
(package (inherit glibc)
(arguments
(substitute-keyword-arguments (package-arguments glibc)
((#:configure-flags cf)
`(--host=i686-pc-gnu
--disable-multi-arch
,@cf))
There are examples of that in base.scm.
Could you add a comment justifying each of these --enable/disable flags?
For instance, I don’t see why nscd would need to be disabled.
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?
When these headers are included, they are used like that
bits/...
so, while they are normally included in the path, it only looks in the
directory bits/ for them not in libpthread/sysdeps/generic/bits/.
Any suggestions?
No, I think that’s more a question for the Hurd hackers, but I’m pretty
sure this ought to work by default. Could you check with bug-hurd or on
IRC?
--- /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?
Thanks,
Ludo’.
Re: [PATCH] gnu: base: Add Glibc-Hurd.
I believe the ‘modules’ field can be omitted.
Done, I forgot to do that in the first place :P
+(propagated-inputs `((gnumach-headers ,gnumach-headers)
+ (hurd-headers ,hurd-headers)
+ (hurd-minimal ,hurd-minimal)))
Add a one-line comment saying why they’re propagated.
Actually I am not sure, should they be propagated? Linux glibc does it
this way, because
;; Glibc's limits.h refers to linux/limit.h, for instance, so glibc
;; users should automatically pull Linux headers as well.
Should I change it to inputs?
Is --host the only thing that differs from ‘glibc’? If so, we need to
factorize things.
In order for glibc/hurd to build, we need to remove
(string-append --with-headers=
(assoc-ref %build-inputs linux-headers)
/include)
--enable-kernel=2.6.30
;; XXX: Work around undefined reference to `__stack_chk_guard'.
libc_cv_ssp=no
which are linux specific, and add
--host=i686-pc-gnu
--disable-profile
--disable-multi-arch
--disable-nscd
--enable-obsolete-rpc
How do you suggest doing it? :-)
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?
When these headers are included, they are used like that
bits/...
so, while they are normally included in the path, it only looks in the
directory bits/ for them not in libpthread/sysdeps/generic/bits/.
Any suggestions?
Remove #t, otherwise the result of ‘zero?’ is ignored.
Done.
--- /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
Manolis
