Created attachment 530570 [details] emerge --info The problem appeared when I tried to merge json-c into custom ROOT. # USE="static-libs" ABI_X86="64" emerge --root=$PWD json-c -a These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-libs/json-c-0.13.1-r1 to /home/alpha/downloads/initramfs/ USE="static-libs -doc" ABI_X86="(64) -32 (-x32)" Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/json-c-0.13.1-r1::gentoo for /home/alpha/downloads/initramfs/ * json-c-0.13.1.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking json-c-0.13.1.tar.gz to /tmp/portage/dev-libs/json-c-0.13.1-r1/work >>> Source unpacked in /tmp/portage/dev-libs/json-c-0.13.1-r1/work >>> Preparing source in /tmp/portage/dev-libs/json-c-0.13.1-r1/work/json-c-0.13.1 ... * Running eautoreconf in '/tmp/portage/dev-libs/json-c-0.13.1-r1/work/json-c-0.13.1' ... * ERROR: dev-libs/json-c-0.13.1-r1::gentoo failed (prepare phase): * Cannot find the latest automake! Tried 1.16:1.16 1.15.1:1.15 * * Call stack: * ebuild.sh, line 124: Called src_prepare * environment, line 1873: Called eautoreconf * environment, line 725: Called _elibtoolize '--auto-ltdl' '--install' '--copy' '--force' * environment, line 299: Called autotools_run_tool 'libtoolize' '--install' '--copy' '--force' '--automake' * environment, line 440: Called autotools_env_setup * environment, line 393: Called die * The specific snippet of code: * [[ ${WANT_AUTOMAKE} == "latest" ]] && die "Cannot find the latest automake! Tried ${_LATEST_AUTOMAKE[*]}"; After some research, I've found out that this issue appears to be in the autotools_env_setup function in the autotools.eclass. # @FUNCTION: autotools_env_setup # @INTERNAL # @DESCRIPTION: # Process the WANT_AUTO{CONF,MAKE} flags. autotools_env_setup() { # We do the "latest" → version switch here because it solves # possible order problems, see bug #270010 as an example. if [[ ${WANT_AUTOMAKE} == "latest" ]]; then local pv for pv in ${_LATEST_AUTOMAKE[@]/#*:} ; do # has_version respects ROOT, but in this case, we don't want it to, # thus "ROOT=/" prefix; # Break on first hit to respect _LATEST_AUTOMAKE order. # ROOT=/ has_version "=sys-devel/automake-${pv}*" && export WANT_AUTOMAKE="${pv}" && break portageq has_version / "=sys-devel/automake-${pv}*" && export WANT_AUTOMAKE="${pv}" && break done [[ ${WANT_AUTOMAKE} == "latest" ]] && \ die "Cannot find the latest automake! Tried ${_LATEST_AUTOMAKE[*]}" fi [[ ${WANT_AUTOCONF} == "latest" ]] && export WANT_AUTOCONF=2.5 } Here you can see that I've commented out the line with has_version and replaced it with the portageq equivalent. When edited like this, json-c is merged properly, so this might be the issue with has_version.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d8bc00ab64d448863733ecbba9d2f69f96c1889 commit 9d8bc00ab64d448863733ecbba9d2f69f96c1889 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2018-05-13 10:35:49 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-05-13 10:37:49 +0000 autotools.eclass: Added v1.16.1 to _LATEST_AUTOMAKE array. Closes: https://bugs.gentoo.org/655326 eclass/autotools.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ed0e36e7b664078c7b7f2c346ea377f7537385f8 commit ed0e36e7b664078c7b7f2c346ea377f7537385f8 Author: Alexis Ballier <aballier@gentoo.org> AuthorDate: 2018-05-16 12:13:08 +0000 Commit: Alexis Ballier <aballier@gentoo.org> CommitDate: 2018-05-16 12:18:43 +0000 eclass/autotools.eclass: Use proper arguments to has_version checking for automake in /. Bug: https://bugs.gentoo.org/655326 eclass/autotools.eclass | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
Unfortunately, this commit introduced a regression for Prefix. See bug 656512.
The question boils down to, when we are doing cross-prefix, can has_version use target prefix (env EPREFIX) database? Programs in both target prefix (env PREFIX) and build prefix (CONFIGURE_PREFIX) can be executed on the host.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=8207d9c59468ff32600463033821eec20197ca0f commit 8207d9c59468ff32600463033821eec20197ca0f Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2018-06-13 02:12:17 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2018-06-14 01:15:23 +0000 Regard stage3 as BDEPEND in terms of EAPI7. So that build dependencies are satisfied by stage3. Credit: Paul Preney, Byron Grobe, Stephen McCamant, Horea Christian Credit: giacomo.cappellini.87, kuzetsa, Kalon Mills, Joey Chagnon Closes: https://bugs.gentoo.org/655414 Closes: https://bugs.gentoo.org/655326 scripts/bootstrap-prefix.sh | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
(In reply to Larry the Git Cow from comment #5) > The bug has been closed via the following commit(s): Reopening this one as well because moving installed portage around is a bad idea, see bug#655414 comment#52.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=ce515e60309e2e2c51577410b111209eec5754d0 commit ce515e60309e2e2c51577410b111209eec5754d0 Author: Michael Haubenwallner <haubi@gentoo.org> AuthorDate: 2018-06-20 12:02:37 +0000 Commit: Michael Haubenwallner <haubi@gentoo.org> CommitDate: 2018-06-20 12:02:37 +0000 bootstrap-prefix.sh: apply 'stacked-prefix' patch Introducing the 'stacked-prefix' portage FEATURE via temporary patch, subject to be dropped from bootstrap-prefix.sh script once integrated. This replaces commit 8207d9c59468ff32600463033821eec20197ca0f. Closes: https://bugs.gentoo.org/655326 Closes: https://bugs.gentoo.org/655414 scripts/bootstrap-prefix.sh | 71 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 70 insertions(+), 1 deletion(-)
This ended up improving the situation quite a bit: commit 0be276b1530c1e98974b9bc0986ad57f882cb6bf Author: Sam James <sam@gentoo.org> Date: Wed Jun 29 14:26:52 2022 +0000 autotools.eclass: import ::prefix automake has_version edgecase logic During bootstrapping, an automake may not exist yet (which is sometimes fine if an ebuild doesn't actually need it). Make the check non-fatal for prefix where automake doesn't yet exist inside BROOT. We could probably do a bit better here and inspect PATH but this is the logic which has been used in ::prefix for a looong time, and it's currently breaking bootstraps, so let's get it fixed. Signed-off-by: Sam James <sam@gentoo.org> as did: commit 81f5aea4dedb55fdc18723a93ee2ba5d39b3053b Author: Sam James <sam@gentoo.org> Date: Fri Apr 29 02:42:11 2022 +0100 autotools.eclass: drop ROOT=/ in has_version call Noticed when doing a read-through of the eclass (which is how I noticed c8e74a7dfe477dea008548553141f083c5d03782 too). Forcing ROOT=/ is, at best, going to confuse matters, and at worst, do entirely the wrong thing. In EAPI 5 and 6, we had --host-root (which we use in the eclass), and in EAPI 7+, we have -b/-d (which we use in the eclass too). The ROOT= setting was there for pre-EAPI 5 times. The aforementioned toggles (--host-root and then later on, -b/-d) are the correct methods to specify (B)ROOT for has_version. Using one of those with ROOT= have undefined behaviour, so drop it. Bug: https://bugs.gentoo.org/312687 Thanks-to: James Le Cuirot <chewi@gentoo.org> Thanks-to: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org>
