bug-hurd
[Top][All Lists]
Advanced

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

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


From: Manolis Ragkousis
Subject: Re: GSoC: Porting Guix to Hurd week 3+4 report.
Date: Mon, 8 Jun 2015 14:43:35 +0300

Hello Thomas

Actually I did a mistake last time, I should have told you to build gcc-4.8,
not gcc-4.7, because that's what make-bootstrap.scm use.

Btw I managed to build the bootstrap-tarballs. Per Ludo's suggestion I removed
"--disable-decimal-float" flag from %gcc-static and we got the binaries. :-)

> Did that.
>
>> From there:
>>
>>   git clone git://git.savannah.gnu.org/guix.git
>
> (Per Manolis' suggestion, I'm using his GitHub repository.)

I am cleaning up my local patches so we can just use wip-hurd from Savannah.
>
>>   cd guix
>>   git checkout wip-hurd
>>   guix environment guix
>
> (Very pedantically, is that last commant completely "correct"?  My
> understanding is that it sets up an environment for building the version
> of the guix package that is current known to Guix, and not the version
> From the checkout of the wip-hurd branch.  Of course, the underlying
> assumption must be that these two versions have the same dependencies, so
> their environment setup will be the same.)

You are correct, these two versions have the same dependencies, so
their environment setup will be the same.

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

It will be better if Ludo answers that.

> 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:
>
>     $ ls -lrt /var/log/guix/drvs/*/*

> I have not yet made an attempt to understand all of that.  ;-)

Keep in mind that "ls -lrt /var/log/guix/drvs/*/* " will show you all
the logs. You will probably
only need to check the last ones.

>
>> > go to /tmp/nix-build-gcc-4.7...  and there you can find
>> > the failed build. Everything will be there.
>
> 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?)

You will need to patch the source at gcc-4.7 in gcc.scm.To add a new patch,
first place the new patch in gnu/packages/patches/a-new-patch.patch,
then add it in gnu-system.am
in the base directory under "patchdir" and the add it in the source
field of the package you want.
Search for "patches" inside gnu/packages/ in files *.scm on how to do
that. There are plenty of examples.

> Also, in case it should be necessary to restart this build step from
> scratch, do I just remove the /tmp/nix-build-gcc-4.7.4.drv-0/build
> directory, and then run the same guix build command again?

You just rerun the same command. It will just create a new one (drv-1,
2, 3 and so on) in /tmp.
No need to delete anything.

> In case I need to modify the build instructions of an earlier build step,
> I guess I need to do this "the Guix way", that is, edit the respective
> *.scm file, and re-run guix build?  Do I need to invalidate the earlier
> build, or will that happen "automatically"?  How do I patch the sources
> of an earlier build step, that is, rebuild a package using the same build
> instructions but with a different set of sources (say, from a local Git
> checkout)?

It will happen "automatically". You patch the source of each package in the way
I described you above. If you want to change the source, you just
change the source field
of the package. Search for "git-fetch" in gnu/packages and you will
understand how to make it
use a remote git (I am not sure how to make it use a local repo, Ludo
please help :-)). Keep in mind
that everytime you change the source you should update the hash of
those sources. You can get the
hash of a source tarball or a git repo with "guix hash".

Manolis



reply via email to

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