[Top][All Lists]

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

Re: GSoC: Porting Guix to Hurd week 3+4 report.

From: Ludovic Courtès
Subject: Re: GSoC: Porting Guix to Hurd week 3+4 report.
Date: Mon, 08 Jun 2015 14:59:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Thomas Schwinge <thomas@codesourcery.com> skribis:

> On Thu, 04 Jun 2015 22:48:48 +0200, ludo@gnu.org (Ludovic 
> =?utf-8?Q?Court=C3=A8s?=) wrote:
>> Manolis Ragkousis <manolis837@gmail.com> skribis:


>>   autoreconf && ./configure --localstatedir=/var \
>>     --with-libgcrypt-prefix=/gnu/store/... && make
> (Not relevant right now, but why is the libgcrypt path not communicated
> via the environment variables set up with guix environment?  Is that just
> because there are no appropriate environment variables, or something
> else?)  Also, I wanted to note that I, very guixy, computed that path
> using:
>     $ guix build libgcrypt
>     warning: failed to install locale: Invalid argument
>     /gnu/store/r16v30hlw2d6n232rm37p53qy8rpr7f2-libgcrypt-1.6.3
>     /gnu/store/42ls5n7k6lai1k6xfa8v8wks7nn9g3gn-libgcrypt-1.6.3-debug

Yes, that’s fine.

> Next, I ran:
>     $ ./pre-inst-env guix build --target=i686-pc-gnu gcc-4.7 -K -c 8
>> > After it fails
> ..., and eventually reproduced the problem.  However, that took a series
> of steps that was much longer that I had anticipated:

It turns out that hydra.gnu.org is not (yet) serving pre-built binaries
for this branch, so you ended up rebuilding the world, including doing a
complete bootstrap of the distro (info "(guix) Bootstrapping").

I realize this is terribly inconvenient, so apologies for that!

I hope we can soon merge the changes to the “core” packages in the
‘core-updates’ branch, and have ‘wip-hurd’ contain only very specific
patches.  That way, most of the things will have pre-built binaries
available on hydra.gnu.org.

> Assuming I need to patch the GCC sources, do I just do that in
> /tmp/nix-build-gcc-4.7.4.drv-0/gcc-4.7.4/, and then, to continue the
> build, just run the same guix build command again?  (I guess I'll also
> have to preserve my changes elsewhere, as that temporary working tree
> will be removed upon a successful build?)

The simplest way is to use the --with-source option of ‘guix build’,
which allows you to specify an alternate source tarball (info "(guix)
Invoking guix build").

Now, from a discussion we had on IRC, I think the problem reported at
the beginning of this thread is fixed.  Manolis, can you confirm?

Also, I think the target should be 4.9 or 4.8, but definitely not 4.7.
See also

Thank you!


reply via email to

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