| Summary: | coreutils failed to cross-compile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Radek Podgorny <radek> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ansla80, bertrand, jacobgodserv, marat, redhatter, ryan, tibor.vago |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 222797 | ||
| Bug Blocks: | |||
| Attachments: |
Build log showing failure
Build log after help2man |
||
|
Description
Radek Podgorny
2005-05-15 05:06:20 UTC
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 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. |
