*mark_weaver is successfully bootstrapping Guix on MIPS N32 YeeLoong :) <mark_weaver>It's going slowly but smoothly. No problems since applying the workaround (make sure /tmp and /nix/store are on different filesystems). On my YeeLoong, Guix has built make-boot0, diffutils, findutils, binutils-cross-boot0, and it's currently working on gcc-cross-boot0. <viric>mark_weaver: the new kernel fixed all? <mark_weaver>what fixed everything is the following workaround: make sure that /tmp and /nix/store are on different filesystems. <mark_weaver>the reason is that 'pwd' needs to be able to detect mountpoints, so that it will cope with the fact that the inode numbers of mount point directories might be different on the inside and outside. <mark_weaver>the way this is normally done is by checking to see if the device number (as reported by stat) is different between a directory and its parent. <mark_weaver>but that fails to detect bind mounts that mirror part of the same filesystem. <mark_weaver>I confess that I don't yet understand why I didn't run into the problem on my Debian x86_64 system, where /tmp and /nix/store are the same fs. <mark_weaver>I'd still like to investigate further, but at least now I can investigate while the build is happening :) <mark_weaver>btw, the linux-libre-3.10.15 kernel for gnewsense/loongson worked fine on my machine except for one serious problem: the kernel panics fatally very soon after connecting to the network. <mark_weaver>unfortunately most of the information scrolls off the screen very quickly, so I can't provide more details at present. <mark_weaver>I believe there's a hardware serial port on the yeeloong, but it's not easily accessible. <mark_weaver>My YeeLoong successfully built gcc-cross-boot0, now on to perl <mark_weaver>interesting: guix has announced that it will build _four_ distinct derivations of perl-5.16.1. <mark_weaver>gbi0h2bvapfwdss1p2y2qmi47w17qcbh-perl-5.16.1.drv, ii9yjc8d2v05dcnqr4293wxrmn3v4c0k-perl-5.16.1.drv, n1h3vamxkhs0df2zjzyvlcsfvlfzqhcw-perl-5.16.1.drv, and qpfl5yagzijp0k81g1z21xd9mq813yrq-perl-5.16.1.drv <civodul>mark_weaver: you'll need to tell us more about the magic going on on your MIPS box :-) <mark_weaver>nice progress on MIPS N32 bootstrap, but it hit an error on glibc-intermediate-2.18 <mark_weaver>while trying to build io/fcntl.o, the following error occurred: <mark_weaver>In file included from ../ports/sysdeps/unix/sysv/linux/mips/mips64/n32/fcntl.c:1:0: <mark_weaver>../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel': <mark_weaver>../sysdeps/unix/sysv/linux/i386/fcntl.c:37:1: error: '__NR_fcntl64' undeclared (first use in this function) <mark_weaver>../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__libc_fcntl': <mark_weaver>../sysdeps/unix/sysv/linux/i386/fcntl.c:53:1: error: '__NR_fcntl64' undeclared (first use in this function) <mark_weaver>in my home-grown system, __NR_fcntl64 is defined in /usr/include/asm-generic/unistd.h <mark_weaver>and that file is also in /nix/store/8rcvbd897lpbi1cwzrhdnb4aj8dj8c17-linux-libre-headers-3.3.8/include/ which was in CPATH during the build attempt.. hmm <civodul>if you --keep-failed, maybe you can get there, "source environment-variables", and see what's going on <civodul>having the idea is not the difficult part ;-) <mark_weaver>hmm, will the use of -nostdinc on the compile line mean that CPATH is not checked? <mark_weaver>well, it doesn't matter, since -isystem /nix/store/8rcvbd897lpbi1cwzrhdnb4aj8dj8c17-linux-libre-headers-3.3.8/include/ was given also <mark_weaver>civodul: on another matter: one bug I've noticed is that if I run 'guix-daemon' while the umask is 002, it misbehaves, during bootstrap at least. <mark_weaver>it creates directories in /nix/store with group writable perms, and then subsequently fails because of "suspicious" permissions. <mark_weaver>so I have to manually set umask to 022 before running guix-daemon. <civodul>'test-env' protects against that for the tests <civodul>but we don't do anything for the final install <civodul>so i guess guix-daemon.cc should set the umask <civodul>dunno why i didn't fix it this way before <mark_weaver>civodul: out of curiosity, is /tmp and /nix/store on the same filesystem on most nixos systems? <mark_weaver>ah, I think I now partly understand why 'pwd' usually works, but not from the cross-built bootstrap binaries. <mark_weaver>in the x86_64 bootstrap binaries, and on the native 'pwd' on my home-grown system, 'pwd' uses the 'getcwd' system call to find the pwd <mark_weaver>however, in the cross-built 'pwd', it does the job manually by iterating up one directory at a time, and comparing the inode numbers. <mark_weaver>and that manual iteration fails for private bind mounts. <mark_weaver>I suspect that after I've built the bootstrap binaries natively, it will use 'getcwd'. <civodul>so it could be a matter of setting the right build flags for the cross-built Bash? <mark_weaver>well, it's not just bash, it's also pwd from coreutils. <civodul>probably a configure script makes conservative assumptions when cross-compiled <mark_weaver>i guess it warrants investigation.. but for now, we could warn users in the manual that when porting, they may need to ensure that /tmp and /nix/store are on different filesystems. <civodul>sysdeps/unix/sysv/linux/getcwd.c actually includes the generic sysdeps/posix/getcwd.c that does the walking <mark_weaver>and pwd in coreutils also has its own independent code to do the walking <civodul>but normally that generic_getcwd in libc is only used as a fallback is getcwd(2) returns ENAMETOOLONG <mark_weaver>civodul: it might be easier to look into why 'pwd' is failing. there's a lot of logic in lib/getcwd.c to determine whether the syscall can be used. <mark_weaver>also, 'pwd' is the case where I've verified that the x86_64 bootstrap binary uses the system call, but the cross-built MIPS bootstrap binary doesn't. <civodul>mark_weaver: is it easy for you to check if libc's getcwd uses the syscall? <mark_weaver>is there an easy way to find the build log file, given the output directory name in /nix/store ? <civodul>yes, it's in /var/log/nix/drvs or something like that <civodul>we should add a command to do the mapping <mark_weaver>civodul: strace on "guile -c '(getcwd)'", where 'guile' is the one from the cross-built bootstrap binary, reveals that it uses the 'getcwd' syscall. <civodul>then it must be Coreutils/Gnulib doing something crazy <civodul>the initial issue was with Bash, right? <mark_weaver>civodul: I know that it's in $PREFIX/var/log/nix/drvs, but the hash doesn't match. <civodul>mark_weaver: it's the hash of the .drv yes <mark_weaver>if I can find the right one, then I can compare the log files of the cross-built 'coreutils' with the native one. <mark_weaver>and see how they differ in their probing of getcwd related stuff *civodul will be AFK for 1h <civodul>or you could look into Gnulib's module directly <mark_weaver>it would be good if we had a way to find the logs of an already built output. <mark_weaver>e.g., I know that ~/.guix-profile/bin/pwd --> /nix/store/z08cxv0d3mcw1faifj6wzwrvv4r1dm78-coreutils-8.21/bin/pwd, now I want to see the corresponding build log. <mark_weaver>civodul: some relevant differences between the build output of the cross-built coreutils: <mark_weaver>"checking whether getcwd handles long file names properly... no" (whereas for native-built, the answer is "yes") <mark_weaver>and: "checking whether getcwd aborts when 4k < cwd_length < 16k... yes" (whereas for native-built, the answer is "no") <mark_weaver>also, in the cross-built output, I see: "-e 's/@''GNULIB_GETCWD''@/1/g' \\" and "-e 's/@''GNULIB_GETCWD''@/1/g' \\" <mark_weaver>and I don't see those substitutions in the native-built one <mark_weaver>sorry, that should have been: "-e 's/@''GNULIB_GETCWD''@/1/g' \\" and "-e 's|@''REPLACE_GETCWD''@|1|g' \\" <mark_weaver>(in the cross-built, but not the native-built coreutils build output) <mark_weaver>civodul: regarding my troubles with __NR_fcntl64 not being defined: the reason is that /nix/store/2w4mry5mgnms92zimivhi82bb38mba3a-glibc-bootstrap-0/include/asm/unistd.h is apparently tailored for Intel systems, not MIPS. It starts with "#ifndef _ASM_X86_UNISTD_H" and proceeds to use "# ifdef __i386__" to decide whether to include <asm/unistd_32.h> or <asm/unistd_64.h>, and it chooses the wrong one. <mark_weaver>well, more generally, that entire "include/asm" directory seems to be for x86, not MIPS <viric>mark_weaver: include/asm is a link to linux headers include/asm <viric>It mainly means the kernel headers are wrong. <mark_weaver>civodul: when building glibc-intermediate-2.18, CPATH is set to: /nix/store/r9220h2n9ry109rz70r6iiffagah7kjm-gcc-cross-boot0-4.7.3/include:/nix/store/2w4mry5mgnms92zimivhi82bb38mba3a-glibc-bootstrap-0/include:/nix/store/8rcvbd897lpbi1cwzrhdnb4aj8dj8c17-linux-libre-headers-3.3.8/include <viric>those 3.3.8 should be headers for mips <mark_weaver>if it had put /nix/store/8rcvbd897lpbi1cwzrhdnb4aj8dj8c17-linux-libre-headers-3.3.8/include before /nix/store/2w4mry5mgnms92zimivhi82bb38mba3a-glibc-bootstrap-0/include, it probbaly would have worked. <mark_weaver>the /nix/store/8rcvbd897lpbi1cwzrhdnb4aj8dj8c17-linux-libre-headers-3.3.8/include/asm headers are for MIPS, as they should be <mark_weaver>but the /nix/store/2w4mry5mgnms92zimivhi82bb38mba3a-glibc-bootstrap-0/include/asm are for X86, not MIPS. <viric>mark_weaver: in my glibcs, glibc/include/asm is a *symlink* to linux headers <mark_weaver>viric: right, the kernel headers put into the glibc bootstrap binaries are wrong <mark_weaver>viric: yeah, on my Guix/x86_64 system, include/asm is also a symlink to the linux headers. <viric>you have a bad recipe for making the bootstrap pieces. :) <mark_weaver>but glibc-bootstrap-0/include/asm/ is a copy of the wrong headers. <mark_weaver>viric: indeed, and my recipe was: guix build bootstrap-tarballs --target=mips64el-linux-gnu <mark_weaver>I think that %glibc-stripped in make-bootstrap.scm should not be using 'linux-libre-headers' as the input. <mark_weaver>yeah, I see that linux-libre-headers sets ARCH to be the local arch. I guess we need something like 'cross-linux-libre-headers' <viric>that's how it's done in nixpkgs <mark_weaver>I suspect that civodul can fix this much more easily than I can. I'll wait for him. <mark_weaver>(or at least he can advise me on how he'd like it done) <mark_weaver>linux-libre-headers-cross-mips64el-linux-gnu was built correctly during the cross-build, but those weren't the ones used to populate the cross glibc. <mark_weaver>oops, I just missed Nikita by a few minutes... sorry Nikita! <mark_weaver>interesting: I see that 'cross-libc' in cross-base.scm already takes care of generating cross linux headers, and does so properly. <mark_weaver>'%glibc-stripped' in make-bootstrap.scm uses 'cross-libc' as an input, but then it also adds an incorrect (non-cross) linux-libre-headers as another input. <mark_weaver>I guess maybe the answer is to remove the incorrect 'linux-libre-headers' input, and instead arrange to copy the asm headers via the symlink from 'cross-libc'. <civodul>mark_weaver: that header thing is fishy <civodul>i mean that's surprising it retains a valid reference to x86 headers <civodul>the cross-libc definitely works since we can build valid binaries <mark_weaver>civodul: %glibc-stripped uses 'copy-recursively' to copy include/asm from the (non-cross) linux-libre-headers. <civodul>linux-libre-headers is in 'inputs', not 'native-inputs' <mark_weaver>although its other input, (cross-libc target), should include include/asm as a symlink to the correct (cross) headers. <civodul>that means that when cross-compiling, you get a cross-linux-libre-headers <civodul>well you need both asm and asm-generic from Linux <civodul>oh but linux-libre-headers does not seem to be cross-compilation-aware <civodul>it always sets ARCH to the current system, not the target <mark_weaver>so the 'xlinux-headers' within 'cross-libc' is redundant? <civodul>there's an xlinux-headers in cross-base.scm <civodul>it's not even clear that there's much to clean <mark_weaver>is there an easy fix to make linux-libre-headers cross-compilation-aware? <civodul>you can try to just run "guix build linux-libre-headers --target=mips64el-linux-gnu" for a start <viric>this so simple patch pulls me a bit more into guix *civodul will be back on-line later <mark_weaver>"guix build linux-libre-headers --target=mips64el-linux-gnu" works properly, at least. ***ae is now known as Guest9265
<mark_weaver>civodul: your suggested patch seems to have fixed that problem. I just finished compiling new MIPS N32 bootstrap tarballs, and just started a fresh bootstrap on my YeeLoong. <Guest9265>mark_weaver: Excellent! The patch could probably go straight to core-updates. <mark_weaver>it might even be able to go into master. if I understand correctly, it shouldn't change the usual derivations at all. <mark_weaver>well, I'm not actually sure. I need to look more carefully. <civodul>i checked and it doesn't change the current derivations <civodul>i'll see if xlinux-headers can be removed, too <civodul>you'll have to fire up your MIPS box ;-) <Guest9265>Yes indeed. I am waiting for someone to send me the files and tell me where to put them. <Guest9265>Apart from that, I am just compiling a sample qt program. <civodul>Guest9265: oh, sounds like good news <civodul>i have pavucontrol, that gtkmm app for PulseAudio <civodul>viric: i told you: i'm an ex Lennart fan :-) <viric>ah really? I didn't remember <civodul>i think pa is the right approach to the problem, and it works pretty well now <mark_weaver>Guest9265: if you're eager to start bootstrapping MIPS N32, I can send you the bootstrap tarballs I built <mark_weaver>or you can build them yourself from the wip-loongson branch on an Intel box (not sure if it has to be 64-bit or not) *civodul hopes hydra will be back up soon <zacts>hi, what do I need to know to work on guix. is SICP a prerequisite? <Guest9265>zacts: For packaging, no; I started reading the book, but have not finished it yet. <zacts>Guest9265: what would you recommend I read to learn enough scheme to work on the project? <zacts>and would knowing C be helpful? <civodul>but a good contribution to start with is to install it and report any issues <mark_weaver>unless someone is impatient, I plan to wait until I can build MIPS N32 bootstrap binaries natively, which should avoid certain problems. <mark_weaver>and of course, if I get that far, that indicates that most of the problems have been solved. <civodul>mark_weaver: building it natively is gonna take aaaaageees, isn't it? :-) <mark_weaver>yeah, it'll take a while, but that's how I intend to do it. <viric>mark_weaver: what problems do you plan to solve? <Guest9265>And I was only half joking, looking at package examples in the source code is a relatively easy way to get information. I mainly work by copy and paste... <mark_weaver>well, for one thing, with bootstrap tarballs built natively, the problems with 'getcwd' shouldn't happen. <Guest9265>Then, SICP is a good source, starting with the first few chapters. <mark_weaver>but more generally, cross-compiling doesn't work quite as well because the configure script has to make several guesses. <viric>that's just because the native build recipes are correct, and the cross build recepts are not <viric>but the bootstrap tools aren't used for the package building. Only for the later toolchain building. <viric>And getting 'good enough' cross bootstrap tools is a nice situation, I think. :) <zacts>cool I'm watching the 2013 hackers meeting video on guix. way cool! <civodul>mark_weaver: the linux-libre-headers fix doesn't help in anyway for getcwd, right? <mark_weaver>viric: I agree that we should get the cross bootstrap tools "good enough". but it still seems to me nicer to use natively-built bootstrap tarballs in the end. *civodul is starting to lose track re MIPS <mark_weaver>civodul: I wrote here in channel the details about that.. <mark_weaver>civodul: basically, gnulib assumes that 'getcwd' won't be good enough, so it replaces it. <mark_weaver>civodul: search for "civodul: some relevant differences between the build output" <civodul>i don't understand how getcwd could be buggy to the point of needing *that* gnulib module <Steap>civodul: Valgrind is broken because we now use glibc 2.18 (2.17 previously) and we need to regenerate gnu/packages/patches/valgrind-glibc.patch <Steap>But configure.in (which was in the previous diff) does not seem exist <civodul>mark_weaver: so by default it does gl_cv_func_getcwd_abort_bug=yes when cross-compiling, which is not necessary with libc 2.18 <Steap>do you remember how you generated the patch ? <Guest9265>Steap: I already searched for a patch on internet, but did not find any. <civodul>mark_weaver: so i think we can just add #:configure-flags (list "gl_cv_func_getcwd_abort_bug=no"), right? <civodul>well, for all Gnulib-using packages... <mark_weaver>the other one that assumes the worst is gnulib/m4/getcwd-path-max.m4 <mark_weaver>this is your area of expertise. I have trouble reading this m4 code <Steap>Guest9265: well, we just have to add 2.18 in configure.*, they dothat in the git repository <Steap>Guest9265: I'm just wondering whether we should use configure.in, which does not exist... Never really understood the autotools <civodul>Steap: the patch is from Valgrind's repo i think; you can just omit the configure.in hunk <Guest9265>Steap: You mean, we just drop the test whether glibc<=2.17 and pray that things still work? <Steap>Guest9265: looking at the code in valgrind's git repository, that should work with 2.18 <civodul>Guest9265: Valgrind's release dates back to before glibc 2.17, so it needs to be told that things will work (which is the case) <Steap>Damn, mistakenly sent my patch to bug-guix@gnu.org <Steap>Should I resend to guix-devel@gnu.org ?