building libc packages (was: mach_task_self, mach_thread_self, mach_host_self)
Quoting Justus Winter (2015-06-06 11:27:39) Something along these lines? The patch is untested. It compiles fine of course, but despite my best efforts and 8+ hours of cpu time my box failed to build libc packages :/ Well, I disabled the tests, and the -686 and -xen variants. I never came this close to actually building packages, but: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libc0.3/DEBIAN/symbols doesn't match completely debian/libc0.3.symbols.hurd-i386 --- debian/libc0.3.symbols.hurd-i386 (libc0.3_2.19-18justus1_hurd-i386) +++ dpkg-gensymbolsNoCxZ1 2015-06-08 19:39:13.0 +0200 @@ -1,168 +1,168 @@ ld.so.1 #PACKAGE# #MINVER# | #PACKAGE# ( 2.19), #PACKAGE# ( 2.20) - (symver|optional)GCC_3.0 2.3.6 - (symver|optional)GLIBC_2.0 2.0 - (symver|optional)GLIBC_2.1 2.1 - (symver|optional)GLIBC_2.1.1 2.1.1 - (symver|optional)GLIBC_2.1.2 2.1.2 - (symver|optional)GLIBC_2.1.3 2.1.3 - (symver|optional)GLIBC_2.1.4 2.1.4 - (symver|optional)GLIBC_2.10 2.10 - (symver|optional)GLIBC_2.11 2.11 - (symver|optional)GLIBC_2.12 2.12 - (symver|optional)GLIBC_2.13 2.13 - (symver|optional)GLIBC_2.14 2.14 - (symver|optional)GLIBC_2.15 2.15 - (symver|optional)GLIBC_2.16 2.16 - (symver|optional)GLIBC_2.17 2.17 - (symver|optional)GLIBC_2.18 2.18 - (symver|optional)GLIBC_2.19 2.19 - (symver|optional)GLIBC_2.2 2.2 - (symver|optional)GLIBC_2.2.1 2.2.1 - (symver|optional)GLIBC_2.2.2 2.2.2 - (symver|optional)GLIBC_2.2.3 2.2.3 - (symver|optional)GLIBC_2.2.4 2.2.4 - (symver|optional)GLIBC_2.2.5 2.2.5 - (symver|optional)GLIBC_2.2.6 2.2.6 - (symver|optional)GLIBC_2.3 2.3 - (symver|optional)GLIBC_2.3.1 2.3.1 - (symver|optional)GLIBC_2.3.2 2.3.2 - (symver|optional)GLIBC_2.3.3 2.3.3 - (symver|optional)GLIBC_2.3.4 2.3.4 - (symver|optional)GLIBC_2.4 2.4 - (symver|optional)GLIBC_2.5 2.5 - (symver|optional)GLIBC_2.6 2.6 - (symver|optional)GLIBC_2.7 2.7 - (symver|optional)GLIBC_2.8 2.8 - (symver|optional)GLIBC_2.9 2.9 +#MISSING: 2.19-18justus1# (symver|optional)GCC_3.0 2.3.6 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.0 2.0 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.1 2.1 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.1.1 2.1.1 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.1.2 2.1.2 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.1.3 2.1.3 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.1.4 2.1.4 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.10 2.10 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.11 2.11 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.12 2.12 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.13 2.13 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.14 2.14 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.15 2.15 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.16 2.16 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.17 2.17 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.18 2.18 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.19 2.19 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2 2.2 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2.1 2.2.1 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2.2 2.2.2 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2.3 2.2.3 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2.4 2.2.4 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.2.5 2.2.5 + (symver|optional)GLIBC_2.2.6 2.2.6 + (symver|optional)GLIBC_2.3 2.3 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.3.1 2.3.1 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.3.2 2.3.2 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.3.3 2.3.3 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.3.4 2.3.4 + (symver|optional)GLIBC_2.4 2.4 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.5 2.5 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.6 2.6 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.7 2.7 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.8 2.8 +#MISSING: 2.19-18justus1# (symver|optional)GLIBC_2.9 2.9 (symver|optional)GLIBC_PRIVATE 0 1 [... some hundreds of lines looking exactly like that...] dh_makeshlibs: failing due to earlier errors This could be funny if it wasn't so frustrating at the same time... Justus
Re: GSoC: Porting Guix to Hurd week 3+4 report.
Thomas Schwinge tho...@codesourcery.com skribis: On Thu, 04 Jun 2015 22:48:48 +0200, l...@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) wrote: Manolis Ragkousis manolis...@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 http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00052.html. Thank you! Ludo’.
Re: GSoC: Porting Guix to Hurd week 3+4 report.
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
Re: GSoC: Porting Guix to Hurd week 3+4 report.
Hello 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? Yes, I am doing a local cleanup and I am sending the patches to the list. Also, I think the target should be 4.9 or 4.8, but definitely not 4.7. See also http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00052.html. Yes it was a mistake from my part. Manolis
