guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Glibc/hurd work till now


From: Ludovic Courtès
Subject: Re: Glibc/hurd work till now
Date: Tue, 18 Mar 2014 14:32:02 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Manolis Ragkousis <address@hidden> skribis:

> All the changes till now, work in progress, this is not a final patch.
>
>
> Try building the cross-libc for hurd with
> ./pre-inst-env guix build -e '((@@ (gnu packages cross-base)
> cross-libc/hurd) "i686-pc-gnu")'
>
>
> The building process is getting stuck at xhurd-headers recipe.

I think the issue is that xhurd-headers must have --host=i686-pc-gnu in
its configure flags.

You say that in that case ./configure fails with “gcc cannot produce
executables”.  Could you send xhurd-headers’ config.log for that case?

Some additional comments:

> +(define-public glibc/hurd 
> +  (package (inherit glibc)

This definition basically copies all of the ‘glibc’ definition.  This is
fine for now, but eventually this will need to be factorized.

Also, ideally, we’d like to hide the fact that there are two different
glibcs.  So I imagine that we would:

  1. Rename ‘glibc’ to ‘glibc/linux’.

  2. Have ‘glibc/hurd’ inherit from it, just replacing ‘source’,
     ‘propagated-inputs’, ‘inputs’, and adding the pre-configure phase
     that unpacks libpthread.

  3. Define ‘glibc’ as a magic macro that chooses between ‘glibc/linux’
     and ‘glibc/hurd’ depending on the current system/target (see
     ‘pkg-config’ for an example.)

In parallel, we’ll have to lobby so our Hurd friends publish tarballs of
glibc and libpthread.

> +(define* (cross-gcc/hurd target
> +                    #:optional (xbinutils (cross-binutils target)) libc)

Likewise, we shouldn’t need a Hurd-specific variant here.

HTH,
Ludo’.



reply via email to

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