Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 711590 - sys-libs/ncurses-6.2-r1 cross compilation is not working: make: *** progs: No such file or directory
Summary: sys-libs/ncurses-6.2-r1 cross compilation is not working: make: *** progs: No...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Cross compilation support
URL:
Whiteboard: multilib-portage and/or emerge --info...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-05 12:56 UTC by Andrew Aladjev
Modified: 2021-09-20 17:53 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ncurses-6.1.log.xz (ncurses-6.1.log.xz,34.41 KB, application/x-xz)
2020-03-05 12:57 UTC, Andrew Aladjev
Details
ncurses-6.2.log.xz (ncurses-6.2.log.xz,8.17 KB, application/x-xz)
2020-03-05 12:58 UTC, Andrew Aladjev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Aladjev 2020-03-05 12:56:56 UTC
I am trying to cross compile ncurses for mips-unknown-linux-gnu, 6.1_p20190609 works perfect, 6.2-r1 failed with:

make: *** progs: No such file or directory.  Stop.

I will attach 2 logs: for 6.1 and 6.2. Logs are large, I will archive it using xz.

This bug may be related to #563170.


Reproducible: Always
Comment 1 Andrew Aladjev 2020-03-05 12:57:46 UTC
Created attachment 617156 [details]
ncurses-6.1.log.xz
Comment 2 Andrew Aladjev 2020-03-05 12:58:14 UTC
Created attachment 617158 [details]
ncurses-6.2.log.xz
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2020-03-06 09:04:58 UTC
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.
Comment 4 Andrew Aladjev 2020-03-06 10:33:36 UTC
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.
Comment 5 Fabian Groffen gentoo-dev 2021-01-17 14:06:49 UTC
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
Comment 6 Fabian Groffen gentoo-dev 2021-01-17 14:59:27 UTC
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.
Comment 7 Thomas Sachau gentoo-dev 2021-08-21 16:16:39 UTC
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
Comment 8 Mike Gilbert gentoo-dev 2021-08-21 21:13:26 UTC
(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.
Comment 9 Thomas Sachau gentoo-dev 2021-09-19 07:43:56 UTC
(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).
Comment 10 Mike Gilbert gentoo-dev 2021-09-20 14:26:40 UTC
(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.