Re: guix pull fails for me
Hi, guile-json is missing for some reason. Maybe you can install it manually or from a guix git checkout. I'm curious can you provide the guix --version: - as a user - as root - ./pre-inst-env guix --version in git. > ERROR: no code for module (json) > Backtrace: > In ice-9/boot-9.scm: > 157: 12 [catch #t # ...] > In unknown file: >?: 11 [apply-smob/1 #] > In ice-9/boot-9.scm: > 63: 10 [call-with-prompt prompt0 ...] > In ice-9/eval.scm: > 432: 9 [eval # #] > In ice-9/boot-9.scm: > 2401: 8 [save-module-excursion # ()>] > 4050: 7 [#] > 1724: 6 [%start-stack load-stack # ice-9/boot-9.scm:4041:10 ()>] > 1729: 5 [#] > In unknown file: >?: 4 [primitive-load > "/gnu/store/blq0man8glfr3rsb4mya4sgn292z3gr3-guix-latest-guile-builder"] > In ice-9/eval.scm: > 387: 3 [eval # ()] > In > /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm: > 121: 2 [build-guix > "/gnu/store/1w0y78nvmivv6a688ljcdnl35dy8m8i7-guix-latest" ...] > 75: 1 [p-for-each # /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14 > (file)> ...] > In unknown file: >?: 0 [scm-error misc-error #f ...] > > ERROR: In procedure scm-error: > ERROR: process failed # /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:121:14 > (file)> 256 > builder for `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' > failed with exit code 1 > killing process 13118 > guix pull: error: build failed: build of > `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' failed > > > Regards > > Adam Pribyl >
Re: Preliminary 'wip-armhf' branch pushed
John Darrington writes: > On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote: > John Darrington writes: > > > * You patched gcc/config/arm/linux-eabi.h unnecessarily. > > > > Without that patch, GCC actually builds soft-float code, even though > > you may have passed the --with-float=hard flag. What bits of that > > patch do you think are not necessary? > > All of it seems to be unnecessary, by experiment. I've used the > resulting GCC to compile the following test program: > > 'foo' accepts the double arguments via registers and passes a double to > sinh via registers. I also checked a variant that simply returned a*b, > and it was clearly returning the result via register as well. > > I think it's quite clear that this is using the hard-float ABI, no? > > My results showed that simple binaries like that compiled (and ran) > ok. The problems arose when linking with bigger projects. I don't > recall the details. Have you tried building libc? Yes, of course. I looked further into this, and discovered that the reason it all works is that the main 'gcc' driver arranges to pass "-mfloat-abi=hard" (and several others) to 'cc1' and 'as'. Mark
Re: guix pull fails for me
On Thu, 1 Jan 2015, Amirouche Boubekki wrote: Hi, guile-json is missing for some reason. Maybe you can install it Installing guile-json as root makes no difference. manually or from a guix git checkout. I'm curious can you provide the guix --version: guix package -i git is quite a job... even this is a devel list I am just a user here. Got the git clone git://git.savannah.gnu.org/guix.git, but it is not obvious what to do with it. The README in Installation says See manual: info -f doc/guix.info "(guix) Installation" there is nothing like this in cloned repo. Same doc with Installing Guix from Guix requires me to run configure/make but there is no configure in the cloned repo. Running bootstrap ends with: configure.ac:55: error: possibly undefined macro: PKG_CHECK_MODULES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /gnu/store/50qbjh51jaay21gdpv91bff81k1fcqjh-autoconf-2.69/bin/autoconf failed with exit status: 1 Every way I try ends in a dead end. - as a user - as root Both guix --version guix (GNU Guix) 0.7 - ./pre-inst-env guix --version in git. I am not able to get that far... Thanks anyway. Adam Pribyl ERROR: no code for module (json) Backtrace: In ice-9/boot-9.scm: 157: 12 [catch #t # ...] In unknown file: ?: 11 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 10 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 9 [eval # #] In ice-9/boot-9.scm: 2401: 8 [save-module-excursion #] 4050: 7 [#] 1724: 6 [%start-stack load-stack #] 1729: 5 [#] In unknown file: ?: 4 [primitive-load "/gnu/store/blq0man8glfr3rsb4mya4sgn292z3gr3-guix-latest-guile-builder"] In ice-9/eval.scm: 387: 3 [eval # ()] In /gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm: 121: 2 [build-guix "/gnu/store/1w0y78nvmivv6a688ljcdnl35dy8m8i7-guix-latest" ...] 75: 1 [p-for-each # ...] In unknown file: ?: 0 [scm-error misc-error #f ...] ERROR: In procedure scm-error: ERROR: process failed # 256 builder for `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' failed with exit code 1 killing process 13118 guix pull: error: build failed: build of `/gnu/store/gvvn13jys2a65yhh2ildqllyx9alg1zd-guix-latest.drv' failed Regards Adam Pribyl
Problem with natively-built armhf bootstrap compiler
I was able to natively build bootstrap tarballs on the Novena. However, the compiler in these new bootstrap tarballs is broken. The problem is that the new compiler driver (gcc) passes -lgcc_s when linking, but libgcc_s.so does not exist in the gcc bootstrap tarball. It seems that libgcc_s.so does not exist in any of our bootstrap tarballs, so I guess that's intentional. However, for some reason this new bootstrap gcc is trying to link to it. I've done a careful comparison of the output of "gcc -v bare-test.c" between the old (cross-compiled) and new (native-compiled) bootstrap tarballs. bare-test.c contains only an empty main() function. These tests are run outside of the guix-daemon but using only the environment variables set in the 'make-boot0' build. Here are the non-trivial differences: * The GNU triplet is different. The old (working) cross-compiled ones use "arm-linux-gnueabihf", but the new (broken) ones use "armv7l-unknown-linux-gnueabihf", the result of 'config.guess'. * The LIBRARY_PATHs printed by "gcc -v" before running 'collect2' are different. The old (working) cross-compiled one includes ":/lib/:/usr/lib/" at the end, whereas the new (broken) one includes only directories from /gnu/store. * There are several differences in the call to 'collect2': * The old (working) cross-compiled one passes "-dynamic-linker /lib/ld-linux-armhf.so.3" early in the command line, whereas the new (broken) one passes "-dynamic-linker /gnu/store/-glibc-2.20/lib/ld-linux-armhf.so.3". However, both of them pass a second -dynamic-linker argument that points to /gnu/store/*-glibc-bootstrap-0//lib/ld-linux-armhf.so.3 which seems to be correct. * The new (broken) one passes the following extra flags to 'collect2': "-L/gnu/store/-glibc-2.20/lib -rpath=/gnu/store/-glibc-2.20/lib -rpath=/gnu/store/-gcc-static-4.8.4/lib64 -rpath=/gnu/store/-gcc-static-4.8.4/lib -lgcc_s" Obviously, that last -lgcc_s is what's causing problems here. Any idea what's causing this, or how to fix it? Mark
Re: Preliminary 'wip-armhf' branch pushed
On Thu, Jan 01, 2015 at 01:22:53PM -0500, Mark H Weaver wrote: John Darrington writes: > On Thu, Jan 01, 2015 at 02:11:19AM -0500, Mark H Weaver wrote: > John Darrington writes: > > > * You patched gcc/config/arm/linux-eabi.h unnecessarily. > > > > Without that patch, GCC actually builds soft-float code, even though > > you may have passed the --with-float=hard flag. What bits of that > > patch do you think are not necessary? > > All of it seems to be unnecessary, by experiment. I've used the > resulting GCC to compile the following test program: > > 'foo' accepts the double arguments via registers and passes a double to > sinh via registers. I also checked a variant that simply returned a*b, > and it was clearly returning the result via register as well. > > I think it's quite clear that this is using the hard-float ABI, no? > > My results showed that simple binaries like that compiled (and ran) > ok. The problems arose when linking with bigger projects. I don't > recall the details. Have you tried building libc? Yes, of course. I looked further into this, and discovered that the reason it all works is that the main 'gcc' driver arranges to pass "-mfloat-abi=hard" (and several others) to 'cc1' and 'as'. Ok. Right now, I don't remember exactly at what point I discovered the linux-eabi.h changes were necessary, but they were indeed necessary - I didn't do it for fun! I expect you will find out in due course. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: Problem with natively-built armhf bootstrap compiler
Mark H Weaver writes:
> I was able to natively build bootstrap tarballs on the Novena. However,
> the compiler in these new bootstrap tarballs is broken. The problem is
> that the new compiler driver (gcc) passes -lgcc_s when linking, but
> libgcc_s.so does not exist in the gcc bootstrap tarball.
[...]
>* The new (broken) one passes the following extra flags to 'collect2':
> "-L/gnu/store/-glibc-2.20/lib
> -rpath=/gnu/store/-glibc-2.20/lib
> -rpath=/gnu/store/-gcc-static-4.8.4/lib64
> -rpath=/gnu/store/-gcc-static-4.8.4/lib
> -lgcc_s"
These new flags directly correspond to the modification we make to
GNU_USER_TARGET_LIB_SPEC in the pre-configure phase of our gcc-4.7
package in gcc.scm (and inherited by our other gcc packages):
--8<---cut here---start->8---
;; Tell where to find libstdc++, libc, and `?crt*.o', except
;; `crt{begin,end}.o', which come with GCC.
(substitute* (find-files "gcc/config"
"^gnu-user.*\\.h$")
(("#define GNU_USER_TARGET_LIB_SPEC (.*)$" _ suffix)
;; Help libgcc_s.so be found (see also below.) Always use
;; '-lgcc_s' so that libgcc_s.so is always found by those
;; programs that use 'pthread_cancel' (glibc dlopens
;; libgcc_s.so when pthread_cancel support is needed, but
;; having it in the application's RUNPATH isn't enough; see
;;
.)
(format #f "#define GNU_USER_TARGET_LIB_SPEC \
\"-L~a/lib %{!static:-rpath=~a/lib %{!static-libgcc:-rpath=~a/lib64
-rpath=~a/lib -lgcc_s}} \" ~a"
libc libc libdir libdir suffix))
--8<---cut here---end--->8---
It turns out that the "-lgcc_s" above was added just a few days after
we generated our last set of bootstrap tarballs, in commit a7bf595ff.
I guess that ever since that commit, any natively-built bootstrap
tarballs we generated for any platform would have created a broken
compiler, and that this is the first time we've tried since then.
Any suggestions on how best to fix this? My first crude idea is to
simply remove the "-lgcc_s" from %gcc-static. Thoughts?
Mark
TODO: user-environment-hook
Currently, (guix profiles) has code to build 'info-dir' for packages in profile. As mentioned in TODO, IIUC, we should move the code to 'texinfo'. Other usecases include: * hicolor-icon-theme: use gtk-update-icon-cache to get 'icon-theme.cache'. * shared-mime-info: use update-mime-database to get 'mime.cache'. * desktop-file-utils: use update-desktop-database to get 'mimeinfo.cache'. ? glib: use glib-compile-schemas to get 'gschema.compiled'. For schemas, it's always safe for packages in system profile, but may broken for user profile: user had install package A user update the guix disto, A -> A' has incompatible schema change user now install package B' which depend on schema of A' B' will crash if we have schemas from A and B'. If we make A a propagated-inputs of B, dose A will be update to A' when install B'? If so, that's great, we can even get rid of glib-or-gtk-build-system.
Re: Problem with natively-built armhf bootstrap compiler
Mark H Weaver writes: > I was able to natively build bootstrap tarballs on the Novena. However, > the compiler in these new bootstrap tarballs is broken. The problem is > that the new compiler driver (gcc) passes -lgcc_s when linking, but > libgcc_s.so does not exist in the gcc bootstrap tarball. [...] > It turns out that the "-lgcc_s" above was added just a few days after > we generated our last set of bootstrap tarballs, in commit a7bf595ff. > > I guess that ever since that commit, any natively-built bootstrap > tarballs we generated for any platform would have created a broken > compiler, and that this is the first time we've tried since then. > > Any suggestions on how best to fix this? My first crude idea is to > simply remove the "-lgcc_s" from %gcc-static. For now, this is the approach I took, in commit 5336e4c74. Mark
