Question: why macOS was dropped in 1.8.0, and will source builds on macOS arm64 stay possible? #655

Activity

1. luisleo526 commented on Oct 30, 2026

   

   luisleo526

   on Oct 30, 2026

   Last edited by luisleo526

   Collaborator

   More actions

   Thanks for the detailed write-up, and for checking that the macOS arm64 build gives the same trades and net profit as Linux on the #452 control. That is useful to know.

   The short, practical answer:

   1. Why: cost and speed. Paid macOS CI runners cost far more than Linux ones, and the free hosted runners are too slow for the pace we are working at with a test suite this large. So for now CI builds and tests Linux only (x86_64 and arm64), and Linux is the supported platform. That is what the README states ("Supported platforms: Linux x86_64 and arm64"). It was not a design decision against macOS, and nothing in 1.8.0 was built to exclude it.
   2. Source builds on macOS: they are not tested in CI, so they can break without us noticing. We do not set out to depend on Linux-only APIs in the code you build, but we cannot promise a macOS build stays working across releases. The 1.9.0 link fix (one symbol left undefined when linking the shared window-plan library) shows the kind of small break that can happen.
   3. Fixes: small, self-contained fixes that keep the macOS source build working, with no effect on Linux behaviour, are welcome as pull requests. We cannot add a macOS CI leg at this time, for the same cost reason.

   Once the core has converged on Linux, we will reconsider macOS in CI. There is no date for that yet; we will update this issue when it changes.
2. luisleo526 commented on Nov 3, 2026

   

   luisleo526

   on Nov 3, 2026

   Collaborator

   More actions

   Closing this question as answered (see the reply above). If you have a follow-up about building from source on macOS, please reopen this issue or open a new one, and we will answer it there.

   ❤️React with ❤️1Reacted by Tiep Le
3. luisleo526

   closed this as completedon Nov 3, 2026
4. letiep97 commented on Nov 10, 2026

   

   letiep97

   on Nov 10, 2026

   Author

   More actions

   @luisleo526 a follow-up on building from source on macOS, as invited above.

   v1.11.0 (a4472324) does not compile on macOS 15 arm64 as released. v1.10.0 builds unchanged with the same toolchain and options. Two places, both new in 1.11.0:

   1. src/runtime_context.cpp:269 calls ::fdatasync without a platform guard

   src/runtime_context.cpp:269:18: error: no member named 'fdatasync' in the global namespace
     269 |         while (::fdatasync(file) != 0) {
         |                ~~^
   

   macOS has no fdatasync. The other call sites are guarded (src/report_sink_writer.cpp:449, include/pineforge/detail/scratch_file.hpp:686, src/command_scratch_production.cpp:347); this one is not.

   2. src/selected_capacity_csv_reader.cpp:107 uses the floating-point std::from_chars

   src/selected_capacity_csv_reader.cpp:107:30: error: 'from_chars' is unavailable: introduced in macOS 26.0
     107 |     const auto parsed = std::from_chars(begin, text + size, value, std::chars_format::general);
         |                              ^
   

   Apple's libc++ marks the floating-point overloads as available from macOS 26.0, so a build that targets macOS 15 is refused. The integer overloads used elsewhere (src/run_failure.cpp, checked_settings.hpp, live_source_identity.hpp) compile.

   What we changed locally

   • For 1: -Dfdatasync=fsync on the compiler command line.
   • For 2: that one call replaced by strtod_l in the C locale. The function has already scanned the field before the call, so the accepted syntax does not change.

   With both, the Release static library builds and runs run_backtest_full through the C ABI. The v1.11.0 numbers in our reports of 2026-11-10 come from this build. We have not run your test suite on macOS.

   Environment

   macOS 15.8 arm64, Apple clang 17.0.0 (clang-1700.6.3.2), macOS SDK 26.2, CMake 4.4.3. Release, C++17, PINEFORGE_BUILD_SOURCE_LAYER=ON; tests, tutorial, examples, corpus, bench and live runner off.

   Both look like the small, self-contained kind of fix described above, with no effect on Linux: a guard like the one in report_sink_writer.cpp, and a strtod path where the floating-point from_chars is not available.
5. letiep97 commented on Nov 13, 2026

   

   letiep97

   on Nov 13, 2026

   Author

   More actions

   Thank you for #798: on the 1.12.0 release the fdatasync calls no longer need a local change on macOS (macOS 15.8, Apple clang 17, arm64).

   Two notes from the same build, in case they help keep the source build working on macOS:

   • selected_capacity_csv_reader.cpp still calls floating-point std::from_chars, which Apple's libc++ only provides from macOS 26, so on macOS 15 the library still needs a local replacement for that one call.
   • Building all targets (-DPINEFORGE_BUILD_TESTS=OFF, examples, tutorial, corpus, bench and live runner off) stops at bin/pineforge-selected-admit: ld: symbol(s) not found for architecture arm64, _strategy_reads_trade_history, referenced from libpineforge_kernel.a(engine_report.cpp.o). The pineforge library target itself builds and runs.