Re: msys2: Resource temporarily unavailable

[Paul Smith]

On Thu, 2016-04-28 at 12:11 -0700, address@hidden wrote:
>  Thanks everyone.  We're fully aware of the meaning of EAGAIN, and we
>  weren't actually asking what causes this failure, but rather how
>  handles it.  A little experimentation on Linux with LD_PRELOAD gave
>  enough information, but revealed an inconsistency in Make's
>  generation of a failure, and a difference between 3.81 and 4.1.

>   The first observation is that the handling of fork() is different in
>   3.81 and 4.1.  It's not a problem, just an observation.  3.81
>   doesn't show the same failures that 4.1 shows when EAGAIN is
>   encountered.

I hesitate to complain when someone has made the effort to categorize
issues and give examples (thanks for that!).  However, I've never been a
fan of the style of report that gives a few points of interest at the
top followed by a wall of example output intended to show those
points... it takes a frustratingly long time to parse the output and
determine which aspects are intended to show which problem.

If you could intersperse your comments within the example output,
showing which lines in particular you're referring to and describing
exactly what about them you feel is incorrect, and also showing the
alternatives next to each other rather than all the 3.81 then all the
4.1, it takes me much less time to understand the report.

For the above fork() handling issue, I'm not sure if your followup email
discussing the bugs in msys2 have resolved it or not...?

>   The second observation is that an error occurs related to the OS
>   (such as EAGAIN) in the top-level Makefile, Gnu Make prints the
>   diagnostic:
> 
>     make: fork: Resource temporarily unavailable
> 
>   And then summarily exits with return code of two.
> 
>   If the same error occurs in a nested Makefile, then Gnu Make is much
>   chattier about the failure, providing a path of target failures all
>   the way back up to the top level Makefile.

Are you talking about this difference:

>     make indirect-failure
>     make -f Makefile failure
>     make[1]: Entering directory '/work/sources/futzing/preload'
>     if false; then echo "False!" ; else echo "True!"; false; fi;
>     True!
>     Makefile:24: recipe for target 'failure' failed
>     make[1]: *** [failure] Error 1
>     make[1]: Leaving directory '/work/sources/futzing/preload'
>     Makefile:21: recipe for target 'indirect-failure' failed
>     make: *** [indirect-failure] Error 2

vs.:

>     make failure
>     if false; then echo "False!" ; else echo "True!"; false; fi;
>     True!
>     Makefile:24: recipe for target 'failure' failed
>     make: *** [failure] Error 1

The only difference here is precisely because one is a recursive make
invocation and one is not.  Consider this part of the indirect output:

    if false; then echo "False!" ; else echo "True!"; false; fi;
   
True!
    Makefile:24: recipe for target 'failure' failed
    make[1]: ***
[failure] Error 1

This is the same output make generates for the direct case.  Around that are 
Entering/Leaving lines, which are only printed by make (by default) when it is 
recursively invoked:

    make[1]: Entering directory '/work/sources/futzing/preload'
      ...
    make[1]: Leaving directory '/work/sources/futzing/preload'

And around that are the message printed by the parent make when it
invokes the sub-make:

    make -f Makefile failure
      ...
    Makefile:21: recipe for target
'indirect-failure' failed
    make: *** [indirect-failure] Error 2