I was cross-compiling coreutils, i686-pc-linux-gnu -> armv5tel-softfloat-linux-gnueabi, because it's the only one marked stable for arm in the current portage tree, and it failed after not being able to move the 'df' binary. [1] So I went into ${WORKDIR}/coreutils-7.1/src, and 'df' was not even built by the Makefile, although df.c is right there. Looking into the Makefile, I discovered that it's not being built because it's not part of the OPTIONAL_BIN_PROGS variable. If I manually modify the Makefile to include df$(EXEEXT) in the OPTIONAL_BIN_PROGS variable, it fails complaining that get_fs_usage is undefined. Then I went into the lib/ directory to check out fsusage.c, and it was also not being built. This section of config.log showed the reason. [2] The underlying reason was of course in m4/fsusage.m4 . I don't know what to make of this. It compiles fine for x86 natively. I have a sloppy work-around patch for m4/fsusage.h which blindly disregards the message in [2], which allowed me to cross-compile coreutils-7.1 (and 7.2 and 7.4) without issues. Just insert patch with 'epatch' somewhere in src_unpack() in your own ebuild. Any thoughts? ============================================== [1] cross-emerge failure ============================================== mv: cannot stat `df': No such file or directory * * ERROR: sys-apps/coreutils-7.1 failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 2503: Called die * The specific snippet of code: * mv ${fhs} ../../bin/ || die "could not move fhs bins"; * The die message: * could not move fhs bins ============================================== [2] sections of config.log ============================================== ... checking how to get file system space usage ... failed program was: ... #if defined __GLIBC__ && defined __linux__ Do not use statvfs on systems with GNU libc on Linux, because that function stats all preceding entries in /proc/mounts, and that makes df hang if even one of the corresponding file systems is hard-mounted, but not available. statvfs in GNU libc on Hurd, BeOS, Haiku operates differently: it only makes a system call. #endif Reproducible: Always
Created attachment 199763 [details, diff] coreutils-7.1-fix-fsusage-m4.patch
So, maybe I should make it clear what I find confusing. It compiles natively fine on my GLIBC __linux__ x86 machine, without the patch applied. I only encounter the error when I'm cross-compiling ... for a GLIBC __linux__ machine ... a bit of a contradition, no? I haven't really inspected why it fails on one but not the other, so if anyone can make it slightly more clear, and propose a better solution for the rest of the Gentoo universe who needs to cross-compile this package, please do.
*** This bug has been marked as a duplicate of bug 177061 ***
