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