[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