bugmake - Bugs: bug #52922, -Otarget does not function...

 
 

bug #52922: -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

Submitter:  John Hood <cgull>
Submitted:  Thu 18 Jan 2018 02:35:34 AM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.2.1 Operating System:  POSIX-Based
Fixed Release:  4.4 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 31 Aug 2022 02:04:37 AM UTC, comment #13: 

This should be fixed with the latest changes pushed today.

Paul D. Smith <psmith>
Group administrator
Wed 15 Sep 2021 12:46:23 PM UTC, comment #12: 

I'm looking at this and Dmitry's change in bug #60774 this week.  I got sidetracked by some issues being raised for POSIX Issue 8.

Paul D. Smith <psmith>
Group administrator
Wed 15 Sep 2021 11:35:29 AM UTC, comment #11: 

comment #10:

> Is there a number of ports which have gnu make specific makefiles?


Yes.  Depending how you count there's about ~30k ports and about ~4k of them have a build-time dependency on GNU make (I searched the FreeBSD ports tree for "USES=.*gmake").

I'm not a ports maintainer though, I work on PostgreSQL which brought me here.  It happens to use GNU makefiles (BSD make definitely doesn't like them), and gets built and tested after every commit on about 10 operating systems: https://buildfarm.postgresql.org/cgi-bin/show_status.pl

Before patches reach that stage, developer machines and CI systems also run on several operating systems including Macs and FreeBSD, and it'd be nice to be able to use eg make check-world -jN -Otarget to speed things up without garbling the output.

Thomas Munro <tmunro>
Wed 15 Sep 2021 11:09:10 AM UTC, comment #10: 


> I considered fixing that in FreeBSD, but I'm running build farm stuff across a bunch of OSes that all have this problem hence desire to fix it here.



Gentlemen, can you please describe the state of affairs in the bsd world in regards to gnu make? Is there a number of ports which have gnu make specific makefiles? Is there a number of ports which have portable makefiles and you prefer to build them with gnu make?
In other words, what causes you to use gnu make to build bsd ports?

Dmitry Goncharov <dgoncharov>
Wed 15 Sep 2021 05:13:59 AM UTC, comment #9: 

I am still posting too late, but I think what I'm seeing agrees with this-- output directed to a pipe fails but output to a file is OK.  I'll check more carefully tomorrow and update if I'm still wrong.

John Hood <cgull>
Wed 15 Sep 2021 04:50:50 AM UTC, comment #8: 

Yeah, it's implemented at VFS level, so it needs a vnode:

https://github.com/freebsd/freebsd-src/blob/7326e8589cc21431d62f25802eac7c5dd6f74122/sys/kern/kern_descrip.c#L617

I considered fixing that in FreeBSD, but I'm running build farm stuff across a bunch of OSes that all have this problem hence desire to fix it here.

I haven't look at that other patch yet (at a quick glimpse I'm confused about why it's testing every time, but I probably need to actually try it out to have a useful opinion), but I'll be very happy however this gets fixed!

Thomas Munro <tmunro>
Wed 15 Sep 2021 04:41:27 AM UTC, comment #7: 

Oops, I'm posting too late at night.  The problem is still there on FreeBSD.

John Hood <cgull>
Wed 15 Sep 2021 04:36:17 AM UTC, comment #6: 

For the record, this issue seems to be gone on FreeBSD 13.0-- the FreeBSD port is now using GNU Make 4.3, and I don't see this issue now.  The port still doesn't have any patches that seem relevant to this.

It's possible it got fixed on the kernel side, I don't know.

John Hood <cgull>
Mon 13 Sep 2021 12:56:59 PM UTC, comment #5: 


> Maybe this enhancement (using a separate lock file for submakes that are redirected) is something that simply won't be supported on those systems as the effort is not worth the reward.


This confuses users on linux as well.

Dmitry Goncharov <dgoncharov>
Mon 13 Sep 2021 12:42:04 PM UTC, comment #4: 

There was a recent discussion about this. See https://savannah.gnu.org/bugs/?60774 and the mailing list.

Dmitry Goncharov <dgoncharov>
Mon 13 Sep 2021 04:24:47 AM UTC, comment #3: 

Here's a draft patch to create a lock file if an initial test of the output descriptor fails.  Tested on FreeBSD.

I don't currently have any good ideas for how to detect redirection and use a separate lock file.


(file #51900)

Thomas Munro <tmunro>
Fri 19 Jan 2018 10:01:14 PM UTC, comment #2: 

I spent a while longer looking at this, and being reminded of how messy UNIX locking is.

  • On FreeBSD, none of fcntl-locks, flock(), and lockf() work on pipes.


  • POSIX reminds me that write() is atomic on regular files.  If make were to carefully accumulate and concatenate output for stdout and stderr into buffers, and then write() entire buffers, make might not need locking at all for regular files.  Of course, buffers of unbounded size would be a problem here.


  • Network file systems have varying support for locking.


I think having either a lock file or a POSIX semaphore to share with children is probably the best way to handle this.  This loses the redirected-children-dont-lock property, but in output_dump() make is pretty much just copying the temporary output and doing fairly simple sprintfs for its own output.  That should go fairly fast most of the time, and I'd guess concurrency wouldn't be a major problem, except for really pathological cases such as very large numbers of targets or very large output from targets.

John Hood <cgull>
Thu 18 Jan 2018 01:13:08 PM UTC, comment #1: 

Yes, I'm aware of this as I've seen it happen on MacOS systems myself.  Thanks for filing the bug, as I never got around to it.

I've been considering different ways to address the issue including using a lock file on systems where locking of pipes fails.  Using a file that all makes have open is itself not an issue, because the parent make can simply open the file and leave it open when invoking submakes.  We just need to create a way for the parent to notify the submakes which FD to use for locking.  We already do similar things for, for example, the jobserver pipes so this is not breaking new ground.

However, using stdout has the nice feature of automatically working correctly if you redirect output (for example, if you invoke a submake and redirect it's output to a file--that submake doesn't need to participate in the same output locking that the parent does and since the stdout is a different file descriptor that just magically happens).

So far I haven't found the time to sit down and really think about how this could work correctly using a lock file instead of stdout, or what extra effort make needs to go to.  Maybe this enhancement (using a separate lock file for submakes that are redirected) is something that simply won't be supported on those systems as the effort is not worth the reward.

Paul D. Smith <psmith>
Group administrator
Thu 18 Jan 2018 02:35:34 AM UTC, original submission:  

FreeBSD 11.1, GNU Make version 4.2.1 (installed from FreeBSD packages; the distribution patches are small and don't seem relevant here).

On this system, if GNU Make is invoked with options '-j32 -Otarget' and standard output is redirected to a pipe, Make prints the following errors:

jhood@jhood_lfs:/tmp 0 $ gmake -j32 -Otarget | cat
fcntl(): Bad file descriptor
touch foo
fcntl(): Bad file descriptor
touch bar
jhood@jhood_lfs:/tmp 0 $ uname -a

This is because FreeBSD only supports fcntl(..., F_SETLKW, ...) on a few types of files, including regular files and ttys.  Pipes and sockets are not supported.

Locking for other than regular files is not required for POSIX compliance, see http://pubs.opengroup.org/onlinepubs/9699919799/

I think the impact is fairly minimal.  The error message appears, and locking doesn't happen, but since GNU make gathers output and writes it more atomically in this mode, -Otarget should still mostly work.

This isn't a problem on Linux, which does seem to support F_SETLKW on pipes and sockets at least.  I do see the problem on macOS, and I would expect that the problem exists on most/all BSD-derived systems and probably various other POSIX environments as well.

I don't see an obvious easy solution; I think this is intended to work with child invocations of make, and so it's best to use a file that all of them already have open, like stdout.  BSD systems could probably use flock() instead, but choosing flock() over fcntl() in Configure would require figuring out which is the better implementation on a given system.

John Hood <cgull>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by tmunro (Updated the item)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by cgull (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-08-31 psmith StatusNone Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.4
    2021-09-13 tmunro Attached File- Added 0001-Fix-O-portability.patch, #51900

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code