Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

On Sun, Jul 25, 2021 at 10:03 AM Paul Smith <psmith@gnu.org> wrote:
> Writing to
> things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple
> concurrent writers to your printers or your terminal!

The user intentionally redirects make to a printer along with another
tool. Should make be smarter than the user and refuse?
When -O is not specified make will happily run redirected to a printer.


> To me the most compelling reason to change the current locking behavior
> is not this: I agree with David that simply special-casing /dev/null
> could be a good solution; if you're redirecting to /dev/null why even
> HAVE a lock?

Mike wanted to specify -O and redirect to /dev/null. Again, why should
the tool be smarter the user?


> The most compelling reason to change the current behavior is that
> unfortunately BSD-based systems don't support locking file descriptors
> that aren't real files: so if you pipe make's output to something on a
> BSD-based system like MacOS or FreeBSD, for example, you get a ton of
> error messages.

One mechanism to avoid these error messages would be to stat stdout
and check S_IFREG.


>     submake: ; $(MAKE) -C $@ >sub.out
>
> The way the implementation is today, the outer make and the submake
> magically have different "output lock domains",

This is an interesting situation.
i considered this behavior to be a violation of the contract. The make
manual says that when -O is specified the output of the parent and
children is synchronized.
make is a portable tool and this magic does not happen on windows.
i think, we should either fix the deadlock or document that make locks
stdout. Otherwise, you see, the users are confused.


regards, Dmitry