Repository navigation
Build on macOS: fdatasync via F_FULLFSYNC, mkdtemp via <unistd.h> (1.7.0 tag blocker) - #501
Merged
Merged
Conversation
main stopped compiling on macOS (Apple clang 17, macOS 26 SDK). A full
keep-going build of every target the default configuration contains (both
libraries, 673 tests, the tutorial strategies and the native examples; 859
translation units) found exactly two compile errors in three translation
units. Both are fixed here.
* src/command_scratch_production.cpp, CommandScratchFile::do_sync(): macOS
has no ::fdatasync ("no member named 'fdatasync' in the global namespace").
The file is compiled into both pineforge_kernel and pineforge, so this one
error failed both archives and blocked every other target. On __APPLE__ the
ScratchDurability::data case now calls fcntl(fd_, F_FULLFSYNC) and falls
back to ::fsync(fd_) when that fcntl fails; ScratchDurability::full still
calls ::fsync(fd_) and the EINTR retry loop is unchanged. Every other
platform keeps the exact existing ::fdatasync(fd_) call behind the #else, so
Linux behaviour does not change.
* tests/test_report_mode_v1_summary_with_observer.cpp, sink_directory():
::mkdtemp is declared in <unistd.h> on macOS (in <stdlib.h> on glibc) and
the file did not include it, so it failed with "no member named 'mkdtemp' in
the global namespace". Add #include <unistd.h>. No call and no test
expectation changes, and the header is harmless on Linux.
Line counts: src/command_scratch_production.cpp +6 (inserted after line 331);
tests/test_report_mode_v1_summary_with_observer.cpp +1 (inserted after line 19).
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
On macOS fsync does not reach stable storage, so the previous commit gave the stronger ScratchDurability::full mode a weaker flush than data. On __APPLE__ both modes now call fcntl(fd_, F_FULLFSYNC) and fall back to ::fsync(fd_) when it fails. The EINTR loop is unchanged; every other platform keeps the exact ::fdatasync / ::fsync line. Line counts unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the macOS build of engine main b250ceb (blocks the 1.7.0 tag: release.yml dry run 40139809402 macos-universal and main ci-post 40139771498 macos-26 Debug/Release failed). A full keep-going Release build on macOS (Apple clang 17, macOS 26 SDK; both libraries, 673 tests, tutorials, examples; 859 TUs) found exactly two errors; a second full build after the fix: 0 errors.
Linux code path byte-identical (#else keeps ::fdatasync). Line counts change in src/command_scratch_production.cpp (+6): doc anchors citing it are re-pinned in a follow-up commit on this branch if preflight's doc-anchors names any.
--- commit message ---
Build on macOS: fdatasync via F_FULLFSYNC, mkdtemp via <unistd.h>
main stopped compiling on macOS (Apple clang 17, macOS 26 SDK). A full
keep-going build of every target the default configuration contains (both
libraries, 673 tests, the tutorial strategies and the native examples; 859
translation units) found exactly two compile errors in three translation
units. Both are fixed here.
has no ::fdatasync ("no member named 'fdatasync' in the global namespace").
The file is compiled into both pineforge_kernel and pineforge, so this one
error failed both archives and blocked every other target. On APPLE the
ScratchDurability::data case now calls fcntl(fd_, F_FULLFSYNC) and falls
back to ::fsync(fd_) when that fcntl fails; ScratchDurability::full still
calls ::fsync(fd_) and the EINTR retry loop is unchanged. Every other
platform keeps the exact existing ::fdatasync(fd_) call behind the #else, so
Linux behaviour does not change.
::mkdtemp is declared in <unistd.h> on macOS (in <stdlib.h> on glibc) and
the file did not include it, so it failed with "no member named 'mkdtemp' in
the global namespace". Add #include <unistd.h>. No call and no test
expectation changes, and the header is harmless on Linux.
Line counts: src/command_scratch_production.cpp +6 (inserted after line 331);
tests/test_report_mode_v1_summary_with_observer.cpp +1 (inserted after line 19).
Co-Authored-By: Claude Sonnet 5.5 [email protected]
🤖 Generated with Claude Code