This is more a nit-pick than a bug. The Mac OS build was failing for me. There are two places where a sed transformation is applied to headers: ./Source/JavaScriptCore/postprocess-headers.sh @ line 92 ./Source/WebKit/mac/postprocess-framework-headers.sh @ line 84 Inspecting the scripts, the intent is to create a backup file with a '.tmp' extension: sed -i .tmp -E "${SED_OPTIONS[@]}" "${TARGET_TEMP_DIR}/${HEADER_PATH##*/}" || exit $? [Note the space between `sed -i` and `.tmp`] On my system I have 'gnu-sed' installed ahead of the system version and it fails with the following error: sed: can't read .tmp: No such file or directory So the problem is self-inflicted. Most of the manuals I could find for 'standard' sed specify that the 'backup extension suffix' syntax has the `-i` followed by the suffix without any whitespace. '/usr/bin/sed' prints usage information that shows it expects the syntax with whitespace: >/usr/bin/sed --usage /usr/bin/sed: illegal option -- - usage: sed script [-Ealn] [-i extension] [file ...] sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...] Then I tested and the '/usr/bin/sed' version will also accept the 'no-space' syntax. Simply removing the space got me past the problem: sed -i.tmp -E "${SED_OPTIONS[@]}" "${TARGET_TEMP_DIR}/${HEADER_PATH##*/}" || exit $? I'm not sure if this worth changing, it's been this way in the codebase for a long time as is. Searching the bugbase didn't show any related complaints. The entire in-place '-i' option itself is non-standard; it doesn't show in the bare-bones definition: [https://www.unix.com/man-page/posix/1P/sed]