mc-4.8.3 - Install error with fish, fork bomb and system hang on OSX

[2bits]

mc-4.8.3 and 4.8.1.3 have been reported by a half-dozen users on OSX to fail during make -j1 install during the installation of the FISH files in a strange endless series of forks where ps shows many instances of grep and sh being spawned. These failure were reported to ​Homebrew, a package installer, over the last few months. I am reporting here and authoring the current workaround, which is to --disable-vfs-fish for those users. The entire discussion including exhaustive terminal output can be found ​in issue 8587 on the Homebrew website.

The error in short looks like this

Making install in fish
Making install in helpers
make[5]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/Cellar/midnight-commander/4.8.3/libexec/mc/fish" || ../../../../config/install-sh -c -d "/usr/local/Cellar/midnight-commander/4.8.3/libexec/mc/fish"
### 500
### 500
### 000
### 500
### 000
### 000
### 000
 /usr/bin/install -c -m 644 README.fish '/usr/local/Cellar/midnight-commander/4.8.3/libexec/mc/fish'
test -z "/usr/local/Cellar/midnight-commander/4.8.3/libexec/mc/fish" || ../../../../config/install-sh -c -d "/usr/local/Cellar/midnight-commander/4.8.3/libexec/mc/fish"
==> Exit Status: 2

Before I asked the affected users to use j1 during install, the error message also included the reference to fork:

### 000
../../../../config/install-sh: fork: Resource temporarily unavailable
make[5]: *** [install-fishDATA] Error 128
make[5]: *** Waiting for unfinished jobs....
### 500

We made an educated guess that something odd was happening with an older install-sh, and recently asked an affected user to autoreconf -ivf using the latest autoconf-2.69, automake-1.12, and libtool-2.4.2, but this did not succeed in fixing the problem.

Our current workaround is to --disable-vfs-fish but another workaround found on Google was said to be, 'create that directory in advance of make install.' Google found at least one instance of this going back many revisions of mc on a different OS, and you can read that bug report ​here on FreeBSD's site.

I'm hoping to get the affected users to give me their LC_MESSAGES=C mc -V and the other two requested outputs. I'll updated this when I have that info.

[2bits]

The LC_MESSAGES=C mc -V is here: ​https://gist.github.com/2630028
The LC_MESSAGES=C mc -F is here: ​https://gist.github.com/2630038
The mc --configure-options is here: ​https://gist.github.com/2630041
The shell is /bin/bash

[andrew_b]

Please show the config.log file.

[andrew_b]

Normally in linux, make uses mkdir -p to create directories:

test -z "/home/andrew/work.c/mc/mc-master/BUILD_ROOT/INSTALL_ROOT/libexec/mc/fish" || /bin/mkdir -p "/home/andrew/work.c/mc/mc-master/BUILD_ROOT/INSTALL_ROOT/libexec/mc/fish"
 /bin/install -c -m 644 /home/andrew/work.c/mc/mc-master/src/vfs/fish/helpers/README.fish '/home/andrew/work.c/mc/mc-master/BUILD_ROOT/INSTALL_ROOT/libexec/mc/fish'

But even I replace mkdir -p here with ../../../../config/install-sh -c -d, installation is successful for me.

I'm using automake-1.11. Did you try build with this version?

[2bits]

None of the six Homebrew admins nor I can reproduce this bug, but at least six users can on BSD like operating systems (OSX and FreeBSD). So I am at a disadvantage in that I can't accurately define the problem beyond repeat their evidence. I have asked one of the affected users to reply with their config.log. Hopefully that will happen shortly. In case you are curious about the mkdir -p test in the meantime, I get this on my computer with OSX Lion that is not affected by this issue:

configure:3126: checking for a thread-safe mkdir -p
configure:3165: result: config/install-sh -c -d
...
MKDIR_P='config/install-sh -c -d'
...
mkdir_p='$(top_builddir)/config/install-sh -c -d'

You asked if we tried to build this using automake-1.11. I'm confused by that because automake would not be involved unless someone tries to autoreconf -ivf before configure. As I stated in my OP, we tried that using automake-1.12 which has a newer install-sh script than the mc one from 2009, and we still get the fork bombs. You can see the output from the autoreconf attempt ​in this gist, but unfortunately the user did not run

make
make -j1 install

during that attempt. So the failure doesn't happen exactly in the same place. All this info I'm copying from the ​Homebrew issue because you asked and because it might be easier for you to work with all in one place.

[2bits]

The user replied with information on his config.log ​in this comment on Homebrew.

[slavazanko]

Try to apply 2806.patch.

Is patch was helpful?

[andrew_b]

Patch contains the 'cut'n'paste' error. Correct patch is 2806.2.patch.

[andrew_b]

fish and extfs

[2bits]

I will inform the user(s) and provide a result for you as soon as I hear back. Thank you very much for helping with this.

[2bits]

The user reports back that building your repo from git and applying 2806.3 resulted in the exact same error. He was able to get a ​config.log though. The Homebrew formula I gave him to test your patch ​is located here so that you can see the setup if you want. The user did not post his terminal output from the compile. So that's all the data I have for you atm. Thanks again for your time.

[zaytsev]

This must have been fixed by itself during one of the many autotools upgrades.

Currently, parallel installation works on macOS, probably because the test now always results in mkdir -p, but I have also checked forcing install-sh and I was able to install without any problems:

MKDIR_P="$(pwd)/../config/install-sh -c -d" \
  ../configure 

This doesn't mean much though, because in the past the test always resulted in install-sh and most users still couldn't reproduce the problem.

I think that all we can do is to close this as worksforme.