pkg/60628: Darwin gcc binary packages broken on machines without the build host's SDK path

>Number:         60628
>Category:       pkg
>Synopsis:       Darwin gcc binary packages broken on machines without the build host's SDK path
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 21 09:10:00 +0000 2026
>Originator:     Suyun
>Release:        pkgsrc trunk 2026-08; binary set from pkgsrc.smartos.org (Darwin/arm64)
>Organization:
>Environment:
Darwin Ganyu.local 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun  9 22:27:52 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T8112 arm64
>Description:
The lang/gcc* packages (the pattern exists in at least gcc10 through gcc16) produce compilers 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 machine that built the binary package.

This was originally reported against the MNX/Triton binary package sets; the maintainer there asked for it to be filed upstream:
https://github.com/TritonDataCenter/pkgsrc/issues/423

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}
   (each lang/gcc*/Makefile.common) 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/.../SDKs/MacOSX14.5.sdk

   which does not exist on install machines (different Xcode
   location/version, renamed Xcode bundle, 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 and the output is shipped verbatim.  On machines with a newer
   SDK these headers shadow the real system headers and can be
   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), so _stdio.h is 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.

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.

Possible approaches exist and have been explored (details can be
provided), but the choice seems worth a community decision, hence this
report without a prescribed fix.  Happy to test any approach on
affected machines.
>How-To-Repeat:
Install the gcc15 binary package from the Darwin/arm64 set on a machine without /Applications/Xcode-15.4.app (e.g. CLT-only macOS 26), then:

    $ /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

    $ /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
>Fix:
Not prescribed; see description and linked issue for discussion.