[MacPorts] #73796: muniversal portgroup: Text file merging is broken on Tahoe

[MacPorts]

#73796: muniversal portgroup: Text file merging is broken on Tahoe
--------------------------------+--------------------
  Reporter:  TellowKrinkle      |      Owner:  (none)
      Type:  defect             |     Status:  new
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:  2.12.4
Resolution:                     |   Keywords:  tahoe
      Port:  muniversal, glib2  |
--------------------------------+--------------------

Comment (by jrjsmrtn):

 Another affected port: **libffi**, and this one has a wider blast radius
 than a single
 broken header.

 `libffi @3.4.8_0+universal` produces `/opt/local/include/ffi.h` as a
 96-byte `ar` archive
 instead of a C header:


 {{{
 $ file /opt/local/include/ffi.h
 /opt/local/include/ffi.h: current ar archive random library
 $ head -3 /opt/local/include/ffi.h
 !<arch>
 #1/20           1788259576  0     0     100644  28        `
 __.SYMDEF SORTED
 }}}


 Reproduced from a clean build on 2026-09-01, so it is not a stale
 artefact:
 `sudo port clean --all libffi && sudo port -vs destroot libffi
 +universal`.

 The merge sequence in the build log matches the analysis in #73933
 exactly. `libffi`
 generates a different `ffi.h` per architecture (`config.status: creating
 include/ffi.h`
 runs once per arch), so `cmp` fails, `lipo` fails, and `libtool` then
 "succeeds" by
 writing an empty archive:

 {{{
 Command failed: /usr/bin/cmp -s ".../destroot-
 arm64/opt/local/include/ffi.h" \
     ".../destroot-ppc-intel/opt/local/include/ffi.h" && /bin/cp -v ...

 fatal error: lipo: can't figure out the architecture type of:
     .../destroot-arm64/opt/local/include/ffi.h
 Command failed: /usr/bin/lipo -create ".../destroot-arm64/.../ffi.h" \
     ".../destroot-ppc-intel/.../ffi.h" -output
 ".../destroot/opt/local/include/ffi.h"

 libtool: warning: not a mach-o '.../destroot-
 arm64/opt/local/include/ffi.h'
 }}}

 **Why this one matters more than a single header.** `libffi` is a library
 dependency of
 `python313` and `python314`, so the corrupt `ffi.h` breaks both of them
 under
 `+universal`. Neither reaches the profile run; `Modules/_ctypes` fails to
 compile first,
 with every error cascading from `ffi.h:1:1`:

 {{{
 # python313 @3.13.15
 /opt/local/include/ffi.h:1:1: error: expected identifier or '('
 /opt/local/include/ffi.h:2:3: error: invalid filename for line marker
 directive
 ./Modules/_ctypes/callproc.c:799:17: error: use of undeclared identifier
 'ffi_type_sint'
 ./Modules/_ctypes/ctypes.h:220:36: error: unknown type name 'ctypes_state'
 make[2]: *** [Modules/_ctypes/callproc.o] Error 1
 make[1]: *** [profile-gen-stamp] Error 2

 # python314 @3.14.7
 ./Modules/_ctypes/stgdict.c:378:33: error: expected expression
 make[2]: *** [Modules/_ctypes/cfield.o] Error 1
 make[1]: *** [profile-gen-stamp] Error 2
 }}}

 `configure` compounds the confusion by reporting `checking for libffi...
 yes` and then
 failing every feature probe (`ffi_prep_cif_var... no`,
 `ffi_prep_closure_loc... no`,
 `ffi_closure_alloc... no`), because the header never parses.

 The knock-on effect is that **no port requiring a universal Python can
 build universal**,
 since MacPorts upgrades the Python dependency to `+universal` and that
 build now fails.
 This surfaced while packaging a port whose only use of Python is a build-
 time script:
 depending on `port:python3xx` is correct practice, but it currently
 forfeits `+universal`
 for a reason unrelated to either port.

 Environment: macOS 26.6.2 (25G83) arm64, Xcode 26.6, MacPorts with
 `universal_archs`
 at the default `arm64 x86_64`. `libffi.dylib` itself is fine — `lipo
 -archs` reports
 `x86_64 arm64`; only the header is corrupt, which makes this easy to
 misdiagnose as a
 Python bug.

-- 
Ticket URL: <https://trac.macports.org/ticket/73796#comment:16>
MacPorts <https://www.macports.org/>
Ports system for macOS