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: Mon, 09 Jun 2014 21:27:08 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

Γειά σας!

Manolis Ragkousis <address@hidden> 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 @@
>>> 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?

Thanks,
Ludo’.



reply via email to

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