Add a portability workflow beside the existing matrix - #192
Merged
Conversation
The vendored subprocess.h calls pipe2 and posix_spawn_file_actions_addchdir_np, which glibc only declares under _GNU_SOURCE. The test suite compiles most of its translation units at strict -std=c99, -std=c11 and -std=c++XX, where that macro is not set for us, so those calls reach the compiler undeclared and -Werror=implicit-function-declaration stops the build. This is what subprocess.h's own test/CMakeLists.txt does, for the same reason.
The old copy was a pristine snapshot of subprocess.h@8671cee and is twelve commits behind. Since then upstream gained the SUBPROCESS_HAVE_CWD and SUBPROCESS_SPAWN_REPORTS_EXEC_ERRORS probes, Windows argument quoting and handle-inheritance fixes, a fork/exec path for platforms whose posix_spawn cannot change directory, and pipe ends kept off the standard descriptors. Pristine snapshot again, no local changes.
cmake.yml covers x86-64 Linux, Windows and macOS. What no matrix over runs-on reaches is 32-bit, non-x86 architectures, a second libc, the BSDs, and older macOS deployment targets - and utest.h's format-macro and timing code differs along exactly those axes. Measured on a fork before opening this: 14 of 14 green, including NetBSD 9.4 with GCC 7.5.0 and the four emulated architectures running the full suite. No capability-paths job, unlike subprocess.h's version of this workflow: UTEST_USE_CLOCKGETTIME is derived from the glibc version by the header itself rather than being settable from outside, so a job forcing it would only be able to confirm the path already taken.
sheredom
reviewed
Aug 21, 2026
| # Strict -std=c99/-std=c11/-std=c++XX modes on glibc hide POSIX/GNU | ||
| # declarations the vendored subprocess.h uses unless feature test macros are | ||
| # enabled. | ||
| if(CMAKE_SYSTEM_NAME STREQUAL "Linux") |
Owner
There was a problem hiding this comment.
Hm not sure about this. This means we aren't ever testing with _GNU_SOURCE not defined on Linux. Seems sketchy 🤔
Contributor
Author
There was a problem hiding this comment.
Agreed — scoped to main.c, the only unit that includes the vendored subprocess.h. Everything else now compiles without it.
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
2 participants
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.
cmake.ymlcovers x86-64 Linux, Windows and macOS across four build types andfour compilers, and covers them well. What no matrix over
runs-onreaches is32-bit, non-x86 architectures, a second libc, the BSDs, and older macOS
deployment targets — and this header's format-macro and timing code differs
along exactly those axes. #188, #189 and #191 were all found through
sheredom/subprocess.h's matrix rather than this repository's own CI.
This mirrors that workflow, added beside
cmake.ymlrather than folded into it.Measured before opening this
Run on a fork, where the workflow is not gated: 14 of 14 green.
linux-32-bit,windows-x86musllinux ppc64le,riscv64,s390x,armv7freebsd 14.3,netbsd 9.4,netbsd 10.1,openbsd 7.9netbsd 9.4is the one worth pointing at: it ships GCC 7.5.0, and it passesonly because #191 landed. Before that it failed twice over — on the hidden
PRImacros and on-std=c++2abeing unknown.Two fixes it needs first
_GNU_SOURCEon Linux.maindoes not currently build against modernglibc: the vendored
subprocess.hcallspipe2andposix_spawn_file_actions_addchdir_np, which glibc declares only under thatmacro, and most translation units here compile at strict
-std=c99,-std=c11or
-std=c++XX.cmake.ymldoes not see it because it pins gcc-10 and clangand excludes the default compiler on Ubuntu. subprocess.h's own
test/CMakeLists.txtsets the same macro for the same reason.That commit stands on its own — it fixes the build with the existing vendored
copy.
The vendored
subprocess.hrefresh. It was a pristine snapshot of8671cee, twelve commits behind. Pristine again afterwards, no local changes.One deliberate difference from subprocess.h's version
No
capability-pathsjob. There the paths are chosen by-Dmacros, so CI canforce each one. The analogue here would be
UTEST_USE_CLOCKGETTIME, but theheader derives it from the glibc version itself rather than taking it from
outside, so such a job could only confirm the path already taken. A green tick
that cannot fail is worse than no job.