Summary: | sys-libs/ncurses-6.2-r1 cross compilation is not working: make: *** progs: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Aladjev <aladjev.andrew> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aladjev.andrew, base-system, bugs, grobian, hayley, jstein, mips, sam, tommy, xtkoba |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=563170 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ncurses-6.1.log.xz
ncurses-6.2.log.xz |
Description
Andrew Aladjev
2020-03-05 12:56:56 UTC
Created attachment 617156 [details]
ncurses-6.1.log.xz
Created attachment 617158 [details]
ncurses-6.2.log.xz
It probably comes from the fast that your host has a different version of ncurses installed: src_compile() { # See comments in src_configure. if ! has_version -b "~sys-libs/${P}:0" ; then BUILD_DIR="${WORKDIR}" \ do_compile cross -C progs tic fi multilib-minimal_src_compile } That 'do_compile' call will need to be updated. My mips container has native ncurses version 6.1-p20190609. I've tried to cross compile ncurses 6.2-r1 once again and it failed with the same error: "progs: No such file or directory". Than I've updated native ncurses to 6.2-r1 and cross compilation of ncurses 6.2-r1 works perfect. I am agree with you, this issue can be reproduced if native ncurses version differs from cross compiled one. seeing this on Prefix too, somehow wonder if this is because the ROOT=/ seems dropped compared to when a previous fix was made: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=60687094052f6401808b6931746a4201957c2156 ok, ROOT is not the problem, in my case --with-progs isn't given to configure for the "cross" configure call, it is hidden behind the multilib_native_with call, which apparently isn't triggering here. I've added --with-progs to the do_configure cross case here, because it's obvious that regardless how/what we need to enable building the progs here, for that's the sole intent. This gets me further here. The issue is the difference between src_configure and src_compile: in src_configure, it only enables progs when it compiles for the native abi as can be seen in this line: $(multilib_native_with progs) If you want to re-compile the same version, then src_compile does always call the target progs independent from the current abi. so obviously the progs target is not configured for the none-default abi and then the compile phase fails because of the missing progs target. So either src_configure should always enable progs or src_compile should only call the progs target, when it is running for the native abi. Since the multilib-build eclass has a variable that always returns true when checking for the native abi, the following workaround allows to compile and cross-compile ncurses for now: COMPLETE_MULTILIB=yes emerge -av1 ncurses (In reply to Thomas Sachau from comment #7) Your comment is only relevant when using your portage-multilib fork. It probably has nothing to do with the issue reported in this bug. (In reply to Mike Gilbert from comment #8) > (In reply to Thomas Sachau from comment #7) > > Your comment is only relevant when using your portage-multilib fork. It > probably has nothing to do with the issue reported in this bug. Please stop writing about things you dont know the issue in detail. Some ebuilds (like the ncurses one) using multilib-eclass based cross-compilation will cause issues for any external tool that does cross-compile for other platforms (like compiling for mips on amd64 with a cross-toolchain, the prefix building or cross-compiling x86 on amd64 outside of the eclass like multilib-portage). The issue is the same independent from the tools used to show the issue: The ebuild intentionally disables some parts in configure for none-default ABI (like progs in this case). If somone does use external tools (not the eclass), then the following stages will still be called (in this part compiling the progs part), but since e.g. mips != amd64, configure progs is disabled, so compile progs will fail. I am really not a fan of disabling parts for none-default ABIs within the eclass (just configure, compile and install everything for all ABIs). But as a workaround, you can set "COMPLETE_MULTILIB=yes" in the environment (as already said, the check for native ABI gets overwritten with this). And this will work independent from the tools you use (cross-toolchain, prefix or multilib-portage). (In reply to Thomas Sachau from comment #9) > Please stop writing about things you dont know the issue in detail. Your explanation makes no sense to me. Please open a new bug with a build log demonstrating the problem. *** Bug 820503 has been marked as a duplicate of this bug. *** The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f994975cb3b2a2ff7f4aa8a69c88e3e0f10b68e5 commit f994975cb3b2a2ff7f4aa8a69c88e3e0f10b68e5 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-11-01 02:21:55 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-11-01 02:22:53 +0000 sys-libs/ncurses: enable progs when cross-compiling The native abi detection logic gets confused when cross-compiling, so just always force progs on here and call it a day. Closes: https://bugs.gentoo.org/711590 Signed-off-by: Mike Frysinger <vapier@gentoo.org> sys-libs/ncurses/ncurses-6.2-r1.ebuild | 2 +- sys-libs/ncurses/ncurses-6.2_p20210619.ebuild | 2 +- sys-libs/ncurses/ncurses-6.3.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) |