Ticket #4052 (closed defect: fixed)
Compile failure on OS X 10.5
| Reported by: | kroleg | Owned by: | andrew_b |
|---|---|---|---|
| Priority: | major | Milestone: | 4.8.25 |
| Component: | mc-tty | Version: | 4.8.24 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Branch state: | merged | Votes for changeset: | committed-master |
Description
tty-internal.c: In function ‘tty_create_winch_pipe’: tty-internal.c:82: error: ‘O_CLOEXEC’ undeclared (first use in this function) tty-internal.c:82: error: (Each undeclared identifier is reported only once tty-internal.c:82: error: for each function it appears in.) make[3]: *** [tty-internal.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 bash-3.2$
Attachments
Change History
comment:3 Changed 5 years ago by andrew_b
- Status changed from new to accepted
- Owner set to andrew_b
- Version changed from master to 4.8.24
- Milestone changed from Future Releases to 4.8.25
comment:4 Changed 5 years ago by andrew_b
- Branch state changed from no branch to on review
Branch: 4052_o_cloexec
changeset:28ca5cb128ce3e4e9d59740df443065a396b664a
comment:5 Changed 5 years ago by andrew_b
- Votes for changeset set to kroleg andrew_b
- Branch state changed from on review to approved
comment:6 Changed 5 years ago by andrew_b
- Status changed from accepted to testing
- Votes for changeset changed from kroleg andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [c8046dc845acee5b0c3cf6f9e6e51607947ce1f3].
comment:9 follow-up: ↓ 10 Changed 5 years ago by egmont
- Status changed from closed to reopened
- Resolution fixed deleted
This leaves the files open across execve on OS X, doesn't it?
While BSDs don't support open()'s O_CLOEXEC to create a file with immediately having this flag, they do support a followup fcntl(fd, F_SETFD, FD_CLOEXEC) to set it afterwards. The result is equivalent except if another thread of a multi-threaded app execs between these two steps.
So mc should fall back to fcntl() on OS X. Or, well, since it's not multi-threaded and thus there's no race that O_CLOEXEC could avoid, maybe O_CLOEXEC can entirely be removed and instead just have a following fcntl().
comment:10 in reply to: ↑ 9 Changed 5 years ago by andrew_b
Replying to egmont:
While BSDs don't support open()'s O_CLOEXEC to create a file with immediately having this flag, they do support a followup fcntl(fd, F_SETFD, FD_CLOEXEC) to set it afterwards. The result is equivalent except if another thread of a multi-threaded app execs between these two steps.
We do use fcntl(). And we use O_NONBLOCK | O_CLOEXEC. Can we use O_NONBLOCK | FD_CLOEXEC?
comment:11 Changed 5 years ago by andrew_b
Branch: 4052_sigwinch
Initial changeset:330ff25f3486fdab81fdf7889342337dac05be13
Pipe creation is reimplemented using GLib APIs only: [452e4f8754f83e6c5b009fb0bf6a70382b5b122d].
comment:12 Changed 5 years ago by andrew_b
- Votes for changeset committed-master deleted
- Component changed from mc-core to mc-tty
- Branch state changed from merged to on review
comment:13 Changed 5 years ago by ossi
it's kinda pointless to g_error_free() right before exit(). note that we previously concluded that not to close the pipe, either.
comment:14 Changed 5 years ago by andrew_b
- Votes for changeset set to andrew_b
- Branch state changed from on review to approved
comment:15 Changed 5 years ago by andrew_b
- Status changed from reopened to closed
- Votes for changeset changed from andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [a5c9fa1394bb84a1fab0991c711b2e529c857439].
git log --pretty=oneline 8c243309c..a5c9fa139
