Repository navigation
Gentoo's emerge fails to install packages after replacing GNU coreutils #8837
Description
Activity
I can reproduce this:
$ INSTALL="" $ $INSTALL -v file.txt /tmp/ zsh: command not found: -v
a bootstrap issue: the Makefile needs
installto build/install uutils, but if uutils has already replaced system coreutils andinstallisn't working, the build fails.Fix
Use the just-built
installinstead of the system one. Modify GNUmakefile#L9:
Line 9 in 3b8264a
ifneq ($(wildcard $(BUILDDIR)/coreutils),) INSTALL = $(BUILDDIR)/coreutils install else INSTALL = install endif
This prevents the bootstrap problem when uutils replaces system coreutils.
Tested on macOS.
Hm will try that
Reacted by Cả thế giới là RustAlthough shouldn't other packages work when the install command from uutils-coreutils was already present on the system?
- added a commit that references this issue
on Oct 8, 2025 I've created PR #8847 to fix this bootstrap issue. The solution moves the INSTALL variable definition to after BUILDDIR is set, allowing it to conditionally use the just-built coreutils install command. This prevents the chicken-and-egg problem where emerge can't build uutils because it depends on uutils being functional.
The fix:
- Uses the built coreutils/install binary if available
- Falls back to system install for first-time builds
- Works for both multicall and standalone build modes
- Tested on macOS with both debug and release profiles
@Alxhr0 Could you test this on your Gentoo system when you get a chance?
Sure
Is believing
installwe built instead ofuutils/installwhich is already installed making a sense?I'm not sure I understand?
Oh I see now
@naoNao89 So far there is no difference
zen fails like this
>>> Emerging (1 of 1) www-client/zen-bin-1.16b::guru * zen-bin-1.16b.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking zen-bin-1.16b.tar.xz to /var/tmp/portage/www-client/zen-bin-1.16b/work >>> Source unpacked in /var/tmp/portage/www-client/zen-bin-1.16b/work >>> Preparing source in /var/tmp/portage/www-client/zen-bin-1.16b/work/zen ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/www-client/zen-bin-1.16b/work/zen ... >>> Source configured. >>> Compiling source in /var/tmp/portage/www-client/zen-bin-1.16b/work/zen ... >>> Source compiled. >>> Test phase [not enabled]: www-client/zen-bin-1.16b >>> Install www-client/zen-bin-1.16b into /var/tmp/portage/www-client/zen-bin-1.16b/image -d: function/utility not found * ERROR: www-client/zen-bin-1.16b::guru failed (install phase): * insinto failed * * Call stack: * ebuild.sh, line 136: Called src_install * environment, line 588: Called insinto '/opt/zen' * phase-helpers.sh, line 64: Called __helpers_die 'insinto failed' * isolated-functions.sh, line 121: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=www-client/zen-bin-1.16b::guru'`, * the complete build log and the output of `emerge -pqv '=www-client/zen-bin-1.16b::guru'`. * The complete build log is located at '/var/tmp/portage/www-client/zen-bin-1.16b/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/zen-bin-1.16b/temp/environment'. * Working directory: '/var/tmp/portage/www-client/zen-bin-1.16b/work/zen' * S: '/var/tmp/portage/www-client/zen-bin-1.16b/work/zenI'm currently building uutils-coreutils
So that fix does work for uutils-coreutils, but other packages still fail, which isn't the best
You can try to manually replace system coreutils binaries by GNU's one e.g.
installwhat you doubt.I mean sure I could use install from GNU, but It's not really a good solution when someone would like to use uutils-coreutils as the only coreutils, but they can't because no package can be installed
This suggestion just inverstigation for this bug.
By the way, this is strange... I'm using mmain branch as system coreutils on Arch. So is this something ebuild specific?
I mean I have one idea that could perhaps, be the issue but I'm not exactly sure yet
But I need to figure out if I can build uutils-coreutils as separate binaries so like ls,cat etc, but without them being a symlink to the main multicall binary
For accuracy, is both of uutils/coreutils on your system and you tried to build
0.2.2?yup
Would you extract
installfrom https://archlinux.org/packages/core/x86_64/coreutils/download/ on$HOME/bin,export PATH+=:$HOME/binand emerge?I fixed it!
The issue is when ls,install,cat etc are symlinks, Emerge instead of running ls,install or cat passes the flags directly to the coreutils binary
Reacted by Florian Schmaus- added a commit that references this issue
on Oct 8, 2025 I just made my ebuild build uutils-coreutils exactly how Gentoo builds GNU Coreutils, without the multicall binary
Hmm I think I can close it, since I did find a solution :P
uutils-coreutils: 0.2.2
OS: Gentoo
When trying to emerge any package or even uutils-coreutils again when uutils-coreutils are used instead of the GNU Coreutils, emerge can't install any package with "cryptic" errors
Last thing I tried was to disable the quiet output in the makefile and this is what it tried to run
I suspect emerge tries to use install, but only the argument gets parsed in this case -v and that throws the error
I tried to disable the quiet output in the GNUmakefile, but install shows fine as a command
I tried to emerge the zen-browser later and it failed with the same error just with the -b being parsed to something