[MacPorts] #74350: skalibs records the kernel point release in sysdeps/target, breaking execline and s6 after any macOS update

[MacPorts]

#74350: skalibs records the kernel point release in sysdeps/target, breaking
execline and s6 after any macOS update
-------------------------+---------------------------------
 Reporter:  herbygillot  |      Owner:  (none)
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:
 Keywords:               |       Port:  skalibs execline s6
-------------------------+---------------------------------
 skalibs writes the full compiler target triple, including the Darwin
 ''point''
 release, into `${prefix}/lib/skalibs/sysdeps/target`. Every dependent
 skarnet
 package re-derives that triple at configure time and compares it verbatim.
 Because the recorded string contains the kernel patch version, any macOS
 point
 update makes an already installed skalibs unusable, and `execline` and
 `s6`
 fail to configure:

 {{{
 ./configure: error: target arm64-apple-darwin25.6.0 does not match the
 contents of /opt/local/lib/skalibs/sysdeps/target
 }}}

 Here the installed skalibs had recorded `arm64-apple-darwin25.5.0`.

 == Cause ==

 `skalibs-2.15.0.0/configure`:

 {{{
 607:    target=$($CC_AUTO -dumpmachine 2>/dev/null) || target=unknown
 647: echo "$target" > $sysdeps/target
 }}}

 On macOS `clang -dumpmachine` yields `arm64-apple-darwin25.6.0`; the
 trailing
 `.6.0` tracks the running kernel and changes with every macOS point
 update.

 The consumers compare it exactly, at `execline-2.9.9.1/configure:396` and
 `s6-2.15.0.0/configure:400`:

 {{{
 if test "$target" != "$(cat $sysdeps/target)" ; then
   echo "$0: error: target $target does not match the contents of
 $sysdeps/target"
   exit 1
 fi
 }}}

 == Why this is not only a local problem ==

 MacPorts binary archives are keyed to the Darwin ''major'' version
 (`darwin_25`), not the point release. A skalibs archive built on the
 buildbot
 therefore records whatever kernel that builder was running, and mismatches
 on
 any user whose point release differs. Installing skalibs plus execline or
 s6
 from binaries can fail for that reason alone, and a working source install
 breaks again at the next macOS update. All three ports are currently
 `nomaintainer`.

 == Suggested fix ==

 Pass a target that omits the point release, so the recorded and re-derived
 strings agree and stay stable across macOS updates:

 {{{
 configure.args-append   --build=${build_arch}-apple-darwin${os.major} \
                         --target=${build_arch}-apple-darwin${os.major}
 }}}

 '''Both''' options are needed. Passing `--target` alone makes configure
 treat
 the build as a cross-compile, because it compares target against build at
 `skalibs configure:565`:

 {{{
 if test -n "$target" && test x${build} != x${target} ; then
   cross=${target}-
 }}}

 It then looks for a `${target}-` prefixed compiler and, more importantly,
 refuses to probe the runtime:

 {{{
 ./configure: sysdep devurandom cannot be autodetected when cross-
 compiling. Please manually provide a value with the --with-sysdep-
 devurandom=yes|no|... option.
 }}}

 Setting `--build` to the same value keeps the build native, so
 autodetection
 runs normally.

 The only use the configure scripts make of the string is selecting the
 shared
 library extension:

 {{{
 libc="${target##*-}"
 if test "${libc##darwin}" != "$libc" ; then
   shlibext=dylib
 fi
 }}}

 which still selects `dylib` for `arm64-apple-darwin25`. The three ports
 must be
 changed together, and skalibs rebuilt first, since they must agree on the
 value.

 No patch is attached; the fix will follow as a commit.

 == Verification ==

 Built outside MacPorts against a scratch prefix, on macOS 26.6.2 / darwin
 25.6.0:

  * skalibs 2.15.0.0 configured, built and installed with both options;
    `lib/skalibs/sysdeps/target` recorded `arm64-apple-darwin25`, with no
    cross-compiler warning.
  * execline 2.9.9.1 configured against that skalibs with the same options
 and
    built; `execlineb -c '/bin/echo execline-works'` ran correctly.

 == Steps to reproduce ==

  1. Install skalibs, then apply a macOS point update, or install a skalibs
     binary archive built under a different point release.
  1. `port -s install execline`

 == Environment ==

  * macOS 26.6.2 25G83 arm64, Xcode 26.6 17F113
  * skalibs @2.15.0.0_1, execline @2.9.9.1_0, s6 @2.15.0.0_0

-- 
Ticket URL: <https://trac.macports.org/ticket/74350>
MacPorts <https://www.macports.org/>
Ports system for macOS