checking for mcheck.h... yes checking for mcheck in -lmcheck... no checking for ar... ar checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib checking for a BSD-compatible install... /usr/lib/portage/python3.12/ebuild-helpers/xattr/install -c checking for bison... bison -y checking for makeinfo >= 4.12... ./configure: line 11565: which: command not found no configure: WARNING: Found Makeinfo . 4.12 or later required. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome_systemd-20240924-072513 UNMASKED: Please re-assign to toolchain@ if you get a test failure in C, C++, or Fortran code which makes no sense. /etc/portage/package.unmask/60gcc:<sys-devel/gcc-15.0.9999:15 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-15 * clang/llvm (if any): clang version 19.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/19/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/19 19.1.0 Python 3.12.6 Available Rust versions: [1] rust-bin-1.81.0 * php cli (if any): HEAD of ::gentoo commit e80890b89acf5153aa9d3460c27570a480728901 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue Sep 24 22:19:01 2024 +0000 2024-09-24 22:19:00 UTC emerge -qpvO =app-editors/xemacs-21.5.35-r2 [ebuild N ] app-editors/xemacs-21.5.35-r2 USE="X alsa bignum gdbm gif gpm jpeg png postgres tiff xft -Xaw3d -athena -berkdb -debug -dnd -ldap -motif -nas -neXt -pop -xface -xim"
Created attachment 903684 [details] emerge-info.txt
Created attachment 903685 [details] app-editors:xemacs-21.5.35-r2:20240924-235701.log
Created attachment 903686 [details] emerge-history.txt
Created attachment 903687 [details] environment
Created attachment 903688 [details] etc.clang.tar.xz
Created attachment 903689 [details] etc.portage.tar.xz
Created attachment 903690 [details] logs.tar.xz
Created attachment 903691 [details] qlist-info.txt
Created attachment 903692 [details] temp.tar.xz
Fixed in xemacs-21.5.35-r3. Commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5cfb56344c1caa63e87ce7e3a890b0f62843d1c7
type -P is not gonna work as ./configure scripts run using /bin/sh The correct solution in this case (iterating over all versions of a command in $PATH) is to iterate over PATH itself using IFS=: See guidance at http://mywiki.wooledge.org/BashFAQ/081 With the current fix, xemacs will instead end up with for prog in -P: not found makeinfo is /usr/bin/makeinfo; do ....... done The tinderbox will just report a new bug, this time for malformed behavior when app-alternatives[dash] is installed. ./configure: 1: -P:: not found error: unable to find `--version' in PATH: No such file or directory ./configure: 1: found: not found ./configure: 1: is: not found
(In reply to Eli Schwartz from comment #11) > type -P is not gonna work as ./configure scripts run using /bin/sh Oh, thanks for pointing that out. My /bin/sh has type -P so it passed my tests. So with dash installed it will break? Using type -P was suggested in https://bugs.gentoo.org/646588 so I though I finally could fix a bug quick. :-( Is that suggested fix then leading in the wrong direction?
Thanks for bringing that to my attention. I added a clarification to the tracker bug report. For the use case of "makeinfo", it is equivalent for bash whether you use "type -P" or "command -v", except that the latter is required for dash support. Using "type -P" would help in situations such as trying to find a "true" program. See for example, in bash: $ type -a true true is a shell builtin true is /usr/bin/true $ command -v true true $ type -a ls ls is aliased to `ls -FN --color=auto' ls is /usr/bin/ls $ command -v ls alias ls='ls -FN --color=auto' Note that in a configure script, aliases are never a problem :) but shell builtins are on rare occasion a problem (it depends whether one is trying to find an executable file in order to e.g. copy it somewhere).
The xemacs configure script is doing this: for prog in `which -a makeinfo`; do I assume they are worried that on systems other than Gentoo, the user might have many different versions of `makeinfo` installed on their system. One in /usr/bin, one installed by hand into /usr/local/bin, a third copy in a user install in $HOME/bin, a fourth copy installed by linuxbrew to $HOME/.linuxbrew/bin, a fifth copy to /opt/texinfo/bin which was created by a "curl | bash" install script back in 2014 but the user cannot recall what software needed it... Neither "type -P" nor "command -v" will handle the "which -a" option (-a is for "all"). So in order to apply a patch that upstream will accept, you may need to do this: OLDIFS="$IFS" for p in $PATH; do if test -x "$p/makeinfo"; then prog="$p/makeinfo" mi_verstr=[`$prog --version | sed -n '1s/^.* \([0-9][0-9.]*\)$/\1/p'`] [...] fi done IFS="$OLDIFS" It's easier if they don't bother worrying about dozens of different "makeinfo" commands scattered around the system, though. :)
I missed a line :/ OLDIFS="$IFS" IFS=":" for p in $PATH; do
For the record: I updated the patch to use "command -v" and just limited it to check the returned makeinfo for its version number. Same patch applied by upstream.
Thanks, that seems nicely reasonable too. :) Much appreciated (as someone who follows both the dash and "which" trackers).
