macOS Tahoe vs Command Line Tools 27.0

[posguy99]

Good evening, @McDutchie.

I wanted to throw out that I made the mistake of installing Command Line Tools 27.0 on Tahoe 26.7, and ksh93u+m failed miserably to build. It looks like the SDK for macOS 27.0 is being chosen during the build.

I backed the CLT off to v26.6, and the build succeeds again.

Tomorrow I will spin up 26.7 and 27.0 VM's and do some messing around.

[posguy99]

Well, I'll have to figure out another way to test on 27.x, neither Parallels nor UTM will create a 27.x VM without upgrading the host to 27.x, and I'm not doing that. Let's see if I can capture the breakage from building u+m on 26.7 with CLT 27.0.

[posguy99]

@McDutchie , I can't create a 26.7 either for some reason, but it fails just as noisily on macOS 26.6.2 with CLT 27.0.

Build log attached.

CLT27 Build Fail.txt.zip

ends with...

Total errors: 49
0m00.044s 0m00.276s
1m01.179s 1m37.297s
mamake [cmd/ksh93]: *** exit code 49 making test.ksh
mamake: *** exit code 49 making cmd/ksh93
mamake: *** exit code 125 making test
package: test failed at Sun Sep 20 20:48:16 PDT 2026 in /Users/mwilson/src/ksh/arch/darwin.arm64-64

[McDutchie]

So, just to be clear, it succeeds in building just fine -- it's the regression tests that fail because ksh crashes.

Ugh. This is bad news. I'm still on Sequoia and I don't want to upgrade my machine to Tahoe since I depend on it for work. Guess I'll have to spend god knows how many hours trying to get it to work in a VM so I can debug these crashes. :-/

Thanks for the report.

[avih]

Maybe it's possible to get a stack trace of one of the failing tests?

[McDutchie]

No need to bother. A stack trace is just the first step to debugging such problems.

Update: I've got Tahoe running in a VM now (took some doing, as expected -- had to add "device support" by extracting and installing a MobileDevice.pkg from an Xcode version that otherwise won't even run on my system, and nobody explains this properly anywhere).

Developer Command Line Tools installed too.

Next problem: the C compiler can't actually compile anything as it links to the wrong SDK and uses an unknown architecture (???)

% bin/package make
ld: tapi error: malformed file
/Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk/usr/lib/libSystem.B.tbd:4:20: error: unknown architecture
                   arm64e.x1-macos, arm64e.x1-maccatalyst ]
                   ^~~~~~~~~~~~~~~
 in '/Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk/usr/lib/libSystem.tbd'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
package: cc: failed to compile and link /usr/local/src/ksh93/ksh/src/cmd/INIT/hello.c -- is it a C compiler?

[posguy99]

I got that one too on a fresh 26.6.2 VM, I ended up re-breaking one of my running systems by reinstalling CLT 27.0 on it.

If you look at the build log I attached, there are all sorts of errors/warnings sprinkled through it before it starts running the regression tests.

[posguy99]

@McDutchie ...

Ok, more testing.

I created a new Parallels 26.6.2 VM, and verified I get the hello.c error from bin/package. If I force the macOS 26.5 SDK with:

$ xcrun --sdk macosx26.5 sh bin/package make && xcrun --sdk macosx26.5 sh bin/package test

then HEAD builds without error and passes all regression tests. So it is definitely the choice of SDK the compiler is making that is the problem.

On my real M1/Tahoe 26.6.2 Mac, where bin/package make can get past the hello.c problem, and then fail a bunch of the regression tests, the build complains repeatedly about the build target being 26.x but it is trying to use the 27.x SDK.

(thanks @tvalenta for showing in #596 (comment) how to specify the SDK to use)

[posguy99]

My usual test of a complex program (qemacs) of course has no problem with CLT 27.0 with the 27.x SDK on Tahoe 26.6.2. Grrrr...

[McDutchie]

Right, long story short: this is Apple's fault. Again.

Yes, you're seeing a nice warning in the build log that pipe2() is not available until macOS 27.0. In the meantime, it still does get shipped in the system libraries in Tahoe, where our feature detection system duly detects it. So it gets used. And crashes ksh. Because Apple decided to ship broken, crashing pipe2() code in macOS Tahoe.

Sigh. Life is too short.

Patch that undoes the feature detection on macOS unless the minimum macOS version we're building for is 27.0. Please test.

diff --git a/src/lib/libast/features/lib b/src/lib/libast/features/lib
index 6edb2e5..6af2fbf 100644
--- a/src/lib/libast/features/lib
+++ b/src/lib/libast/features/lib
@@ -403,3 +403,10 @@ tst	macos_strxfrm_bug - note{ macOS strxfrm(3) bug }end execute{
 		return !(strxfrm(NULL,"\xC2\xA7",0) == 0);
 	}
 }end
+
+cat{
+	/* macOS Tahoe ships a broken pipe2() that crashes, thanks apple :-/ */
+	#if _lib_pipe2 && __APPLE__ && __MACH__ && MAC_OS_X_VERSION_MIN_REQUIRED < 270000
+	#undef _lib_pipe2
+	#endif
+}end

[posguy99]

@McDutchie Nope, now I get this, but the patch looks like it applied without error.

iffe: test: macOS strxfrm(3) bug ... yes
iffe: /Users/mwilson/src/ksh-pipe2/src/lib/libast/features/lib:411: missing }end
mamake [lib/libast]: *** exit code 1 making FEATURE/lib
mamake: *** exit code 1 making lib/libast
mamake: *** exit code 1 making all
package: make failed at Mon Sep 21 17:46:56 PDT 2026 in /Users/mwilson/src/ksh-pipe2/arch/darwin.arm64-64

[McDutchie]

The }end it claims is missing is right there in the patch, so something must have gone wrong applying it.

[posguy99]

Missing newline at the end of src/lib/libast/features/lib.

Yes, it builds now.

So why is the behavior different wrt the hello.c compiler test? Two different pre-existing macOS 26.6.2 installs pass that test with no error but install the CLT cold on a 26.6.2 VM and it still fails.

[McDutchie]

The presence of the 27.0 SDK without the 27.0 command line tools appears to be what causes that. <shrug>

[posguy99]

Yeah, I did some more testing, and that's what is happening. If the SDK is there and the tools are not, you get the hello.c error.

[McDutchie]

Fixed in 029aa9b (dev) / 45302a7 (1.0).