Summary
The Darwin binary packages of lang/gcc15 ship a compiler that cannot compile even a trivial program using the C/C++ standard library on any machine whose macOS SDK path or version differs from the bulk build machine's. The same pattern exists in gcc10–gcc16 (all use --with-sysroot=${OSX_SDK_PATH} in their Makefile.common).
Reproduction
Binary package gcc15-15.3.0nb1 from pkgsrc.smartos.org (Darwin/arm64), installed on a macOS 26 machine that has only the Command Line Tools (no Xcode):
$ /opt/pkg/gcc15/bin/g++ hello.cpp # just #include <iostream>
/opt/pkg/gcc15/include/c++/cwchar:49:10: fatal error: wchar.h: No such file or directory
Plain C fails as well:
$ /opt/pkg/gcc15/bin/gcc h.c # just #include <stdio.h>
.../include-fixed/stdio.h:73:10: fatal error: _stdio.h: No such file or directory
Root cause — two stacked issues
1. The build machine's SDK path is baked into the binaries.
CONFIGURE_ARGS.Darwin += --with-sysroot=${OSX_SDK_PATH} resolves via mk/platform/Darwin.mk to an absolute path on the build machine. The published binaries were configured with
--with-sysroot=/Applications/Xcode-15.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk
which does not exist on install machines (different Xcode location/version, or no Xcode at all). gcc -v -E then shows an empty system header search list, so no system header can be found.
2. The packaged include-fixed/ headers are stale for any other SDK version.
fixincludes runs at package build time against the build machine's SDK (14.5), and the output is shipped verbatim. On machines with a newer SDK these headers shadow the real system headers and are structurally incompatible with them. Concretely, on macOS 26: the packaged include-fixed/stdio.h uses the include guard _STDIO_H_, which collides with the guard of the current SDK's _stdio.h (where FILE is now defined). _stdio.h is therefore skipped entirely and compilation fails with 'FILE' does not name a type. Passing --sysroot manually does not help, because include-fixed is searched before the sysroot include directory.
Note that builds within pkgsrc are unaffected because the cwrappers inject -isysroot ${OSX_SDK_PATH} (mk/platform/Darwin.mk); only direct use of the installed compiler breaks.
Request
Opening this for discussion on how this should be addressed for the Darwin packages (and whether the same change should be applied across lang/gcc10–lang/gcc16). Happy to help test any approach on affected machines.
Summary
The Darwin binary packages of
lang/gcc15ship a compiler that cannot compile even a trivial program using the C/C++ standard library on any machine whose macOS SDK path or version differs from the bulk build machine's. The same pattern exists ingcc10–gcc16(all use--with-sysroot=${OSX_SDK_PATH}in theirMakefile.common).Reproduction
Binary package
gcc15-15.3.0nb1from pkgsrc.smartos.org (Darwin/arm64), installed on a macOS 26 machine that has only the Command Line Tools (no Xcode):Plain C fails as well:
Root cause — two stacked issues
1. The build machine's SDK path is baked into the binaries.
CONFIGURE_ARGS.Darwin += --with-sysroot=${OSX_SDK_PATH}resolves viamk/platform/Darwin.mkto an absolute path on the build machine. The published binaries were configured withwhich does not exist on install machines (different Xcode location/version, or no Xcode at all).
gcc -v -Ethen shows an empty system header search list, so no system header can be found.2. The packaged
include-fixed/headers are stale for any other SDK version.fixincludes runs at package build time against the build machine's SDK (14.5), and the output is shipped verbatim. On machines with a newer SDK these headers shadow the real system headers and are structurally incompatible with them. Concretely, on macOS 26: the packaged
include-fixed/stdio.huses the include guard_STDIO_H_, which collides with the guard of the current SDK's_stdio.h(whereFILEis now defined)._stdio.his therefore skipped entirely and compilation fails with'FILE' does not name a type. Passing--sysrootmanually does not help, becauseinclude-fixedis searched before the sysroot include directory.Note that builds within pkgsrc are unaffected because the cwrappers inject
-isysroot ${OSX_SDK_PATH}(mk/platform/Darwin.mk); only direct use of the installed compiler breaks.Request
Opening this for discussion on how this should be addressed for the Darwin packages (and whether the same change should be applied across
lang/gcc10–lang/gcc16). Happy to help test any approach on affected machines.