NetBSD Problem Report #60628

From www@netbsd.org  Fri Aug 21 09:08:09 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1AC411A923B
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 21 Aug 2026 09:08:09 +0000 (UTC)
Message-Id: <20260821090807.B32C41A923C@mollari.NetBSD.org>
Date: Fri, 21 Aug 2026 09:08:07 +0000 (UTC)
From: suyun@aosc.io
Reply-To: suyun@aosc.io
To: gnats-bugs@NetBSD.org
Subject: Darwin gcc binary packages broken on machines without the build host's SDK path
X-Send-Pr-Version: www-1.0
X-From4GNATS: "suyun@aosc.io via gnats" <gnats-admin@NetBSD.org>

>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
>Last-Modified:  Fri Aug 21 09:40:01 +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.

>Audit-Trail:
From: suyun@aosc.io
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/60628: Darwin gcc binary packages broken on machines without
 the build host's SDK path
Date: Fri, 21 Aug 2026 17:30:44 +0800

 To clarify one point in the original report: the baked-in sysroot path


 /Applications/Xcode-15.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk

 comes from the binaries built and published by the MNX/Triton package
 sets (pkgsrc.smartos.org), i.e. it reflects their build machine, not any
 NetBSD-project build infrastructure.  The underlying defect, however, is
 in the shared lang/gcc*/Makefile.common code, so any binary package
 built elsewhere reproduces the same problem with that builder's own SDK
 path baked in.

Home	PR Database Search