[libjulia] Update 1.13 and 1.14 variants

[fingolfin]

I am not aware of ABI changes in either, but it seems sensible to at least switch 1.13 to the beta, which should be close (hopefully identical) in terms of ABI to the final release. Switching this now should help ensure a smoother transition to the final release.

CC @benlorenz @lgoettgens @barche

[fingolfin]

Hmmm... macOS failure on x86_64 is:

[00:00:12] In file included from /workspace/srcdir/julia/src/signal-handling.c:452:
2026-02-14 01:00:12 CEST
[00:00:12] In file included from /workspace/srcdir/julia/src/signals-unix.c:431:
2026-02-14 01:00:12 CEST
[00:00:12] /workspace/srcdir/julia/src/signals-mach.c:914:23: error: 'thread_get_register_pointer_values' is unavailable: not available on macOS
2026-02-14 01:00:12 CEST
[00:00:12]   914 |             machret = thread_get_register_pointer_values(thread, &sp, &registers, registerValues);
2026-02-14 01:00:12 CEST
[00:00:12]       |                       ^
2026-02-14 01:00:12 CEST
[00:00:12] /opt/x86_64-apple-darwin14/x86_64-apple-darwin14/sys-root/usr/include/mach/thread_state.h:61:15: note: 'thread_get_register_pointer_values' has been explicitly marked unavailable here
2026-02-14 01:00:12 CEST
[00:00:12]    61 | kern_return_t thread_get_register_pointer_values(thread_t thread, uintptr_t *sp, size_t *length, uintptr_t *values);
2026-02-14 01:00:12 CEST
[00:00:12]       |               ^
2026-02-14 01:00:12 CEST
[00:00:12] 1 error generated.

But thread_get_register_pointer_values was introduced in the macOS 10.14 SDK, and I thought this was the SDK we used on x86 Darwin. But perhaps I should try it with the 11 SDK there?

[giordano]

But thread_get_register_pointer_values was introduced in the macOS 10.14 SDK, and I thought this was the SDK we used on x86 Darwin.

No, for historical reasons for the x86-64 architecture we use the 10.12 SDK:

Yggdrasil/0_RootFS/gcc_sources.jl

Lines 289 to 300 in 0e27921

	elseif Sys.isapple(compiler_target)
	if arch(compiler_target) == "aarch64"
	libc_sources = [
	ArchiveSource("https://github.com/phracker/MacOSX-SDKs/releases/download/11.0-11.1/MacOSX11.1.sdk.tar.xz",
	"9b86eab03176c56bb526de30daa50fa819937c54b280364784ce431885341bf6"),
	]
	else
	libc_sources = [
	ArchiveSource("https://github.com/phracker/MacOSX-SDKs/releases/download/10.15/MacOSX10.12.sdk.tar.xz",
	"6852728af94399193599a55d00ae9c4a900925b6431534a3816496b354926774"),
	]
	end

But in practice Julia requires 10.14, because that's what LLVM requires nowadays.

[fingolfin]

Ahhh OK. And yeah, I am aware Julia expects 10.14 (and we are using that as deployment target). Anyway, then the solution is easy enough.

[giordano]

In principle we could bump the SDK used in the gcc toolchains, only problem is that I'm not looking forward to rebuilding all the GCC versions 😅 And now we even have a half-decent way to swap the SDK, which makes this need even less pressing.

[fingolfin]

Hrm, still fails on aarch64 macos:

[12:23:01] ld64.lld: error: cannot open -lutf8proc: No such file or directory

Huh??!

Probably unrelated: I am also seeing this:

[12:22:55] /opt/bin/aarch64-apple-darwin20-libgfortran5-cxx11-julia_version+1.14.0/xcrun: exec: line 37: illegal option -s

[giordano]

xcrun is probably https://github.com/JuliaPackaging/BinaryBuilderBase.jl/blob/4820fc6f96319db3c90aec858564ca824bd036d8/src/Runner.jl#L1117-L1161, it's not impossible it's not bullet-proof.

utf8proc is weird, because it should be handled by julia's build system (we don't use the jlls, because it's statically linked)

[fingolfin]

The xcrun issue is JuliaLang/julia#61040; see also JuliaPackaging/BinaryBuilderBase.jl#464

[giordano]

xcrun issue fixed by JuliaPackaging/BinaryBuilderBase.jl#464, now it remains only the utf8proc issue on both macOS platforms. Consistency is important!

[fingolfin]

Many thanks to @benlorenz for figuring out this fix (he is sitting next to me right now, so we communicated verbally ;-))