The coreutils build failes on cross-compile if the stage of running help2man. The problem is it tries to run the target-system binaries which of course fails. The workaround is to omit the "man" dir from SUBDIRS in Makefile.am. Proper way would be to run the build-system binary to accomplism man-pages creation.
no real info here if you read the ebuild you'll see that there's already a workaround in place in src_unpack to prevent help2man from running when cross-compiling
I can see test on CTARGET. But your howto at http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO says: - CTARGET is no longer needed so don't set it ! (step 9)
Even when I set the CTARGET, if fails with: Making all in man make[2]: Entering directory `/var/tmp/portage/coreutils-5.2.1-r6/work/coreutils-5.2.1/man' rm -fr basename.td; rm -fr cat.td; Updating man page basename.1 rm -fr chroot.td; Updating man page cat.1 Updating man page chroot.1 rm -fr cksum.td; Updating man page cksum.1 help2man: can't get `--help' info from cksum.td/cksum make[2]: *** [cksum.1] Error 126 make[2]: *** Waiting for unfinished jobs.... help2man: can't get `--help' info from cat.td/cat make[2]: *** [cat.1] Error 126 help2man: can't get `--help' info from chroot.td/chroot make[2]: *** [chroot.1] Error 126 make[1]: *** [all-recursive] Error 1 Sorry for bothering you but what is the correct way of telling the ebuild I'm cross-compiling?
OK, got it working. I had to set CTARGET to something else than CHOST but it has to be set! Even "xyz" makes the job. Is this really correct?
no, the test is outdated, it should be checking CBUILD instead of CTARGET
Please, check it also at bug 92695.
fixed in portage Bug 92695 is unrelated
This workaround isn't present in coreutils-6.10-r1, but the issue is still there: Making all in man make[1]: Entering directory `/var/tmp/portage/sys-apps/coreutils-6.10-r1/work/coreutils-6.10/man' Updating man page arch.1 help2man: can't get `--help' info from arch.td/arch make[1]: *** [arch.1] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-apps/coreutils-6.10-r1/work/coreutils-6.10/man' make: *** [all-recursive] Error 1 As it doesn't appear to have been fixed upstream, it would be great if the fix could be added to the current coreutils.
And this is the part where I once again swear to never again comment on bugs at 3 in the morning. The workaround is still there (now in src_compile instead of unpack), but for some reason it's still trying to run help2man.
The tarball is missing some files. I have filed the new bug #222797 for that.
Please reopen. This bug occurs with both coreutils-6.10 (stable) and 6.11 (~arch). It must not build man docs if 'noman' feature is enabled and must not run binaries when cross-compiling.
It would seem the problem still exists in coreutils-6.12-r2... I've struck this while trying to cross-compile a new mipsel-uClibc environment. I get the following: make[2]: Leaving directory `/tmp/cross-mipsel-uclibc/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/doc' Making all in man make[2]: Entering directory `/tmp/cross-mipsel-uclibc/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/man' Updating man page arch.1 help2man: can't get `--help' info from arch.td/arch make[2]: *** [arch.1] Error 126 make[2]: Leaving directory `/tmp/cross-mipsel-uclibc/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/man' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/cross-mipsel-uclibc/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12' make: *** [all] Error 2 The file it complains about is of course, a MIPS-I binary in this case... not understood by the host computer, which is x86. beast ~ # cd /tmp/cross-mipsel-uclibc/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/man beast man # file arch.td/arch arch.td/arch: symbolic link to `../../src/arch' beast man # file ../../src/arch ../../src/arch: cannot open `../../src/arch' (No such file or directory) beast man # file ../src/arch ../src/arch: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), not stripped beast man # uname -a Linux beast 2.6.27.2 #1 SMP Sun Oct 26 13:08:32 EST 2008 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
Created attachment 176472 [details] Build log showing failure
Created attachment 176684 [details] Build log after help2man
I added a new line to coreutils-6.12-r2.ebuild: # Also, it's not like we changed the usage on any of these things, # so let's just update the timestamps and skip the help2man step. touch man/*.1 + touch man/arch.1 <------- this is the new line # There's no reason for this crap to use the private version it step out the help2man part, but I got #2nd build.log (attachment) at install
The previous (add "touch man/arch.1" line to ebuild) workaruond is works fine in version coreutils-6.10-r3
Confirming that patch from comment #16 also works with coreutils-6.11 for amd64->arm cross-build. Please reopen bug.
This bug needs to be re-opened, as it applies to coreutils-6.12-r2.
