Created attachment 437948 [details] emerge --info How to reproduce: emerge ct-ng mkdir test-toolchain cd test-toolchain ct-ng avr ct-ng build (in a different console) watch pgrep install-xattr "|" wc -l Here is what's going on. When crosstool-ng is built, the configure script discovers that "install" invocation should be done as "/usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c" (supposedly because I have USE=xattr). This is written in "/usr/lib/crosstool-ng-1.22.0/paths.sh". When "ct-ng build" prepares for building the toolchain, it creates the directory ".build/tools/bin" where it generates scripts for everything recorded in "/usr/lib/crosstool-ng-1.22.0/paths.sh", including the "install" script that invokes "/usr/lib/portage/python2.7/ebuild-helpers/xattr/install". Then ".build/tools/bin" is put in PATH ahead of system paths, and "install something somewhere" is invoked. The local script executes "/usr/lib/portage/python2.7/xattr/install" which executes "install-xattr" which executes "install" which is the same local script, and everything repeats.
To me, the sanest way to fix this would be modifying "install-xattr" so that it stopped examining PATH when looking for the actual "install". "install-xattr" already has an ability to find "install" when no PATH is set, so it's quite simple. It's a straightforward approach that would eliminate the (probably mostly) unneeded complication. It can break some esoteric use cases, but in a completely understandable way. Other than that, the ct-ng ebuild can just patch "paths.sh" (along with the accompanying "paths.mk") by removing the offending line and allowing the build process to use whatever "install' it can find in PATH. It's a hackish way, though, and I don't know (yet) if it will work.
fyi this is not "fork bomb", fork bombs must be superlinear.
(In reply to Pavel Goran from comment #1) > To me, the sanest way to fix this would be modifying "install-xattr" so that > it stopped examining PATH when looking for the actual "install". > "install-xattr" already has an ability to find "install" when no PATH is > set, so it's quite simple. It's a straightforward approach that would > eliminate the (probably mostly) unneeded complication. It can break some > esoteric use cases, but in a completely understandable way. if i changed this, we'd have to test it in all the environments in which install-xattr is used. how can i be sure that removing the $PATH examining code will not break when "install" is installed in a non-standard location? > > Other than that, the ct-ng ebuild can just patch "paths.sh" (along with the > accompanying "paths.mk") by removing the offending line and allowing the > build process to use whatever "install' it can find in PATH. It's a hackish > way, though, and I don't know (yet) if it will work. can you try that and send a patch my way.
Still unfixed as of today.
(In reply to ntzrmtthihu777+gentoo from comment #4) > Still unfixed as of today. I just added 1.23.0 to the tree, but I'm sure it doesn't solve this. I haven't had time to look but can someone check to see if the path to install is hard coded and points to install-xattr? Maybe something as simple as a quick sed can fix thi.
