Add ARM64 (Apple Silicon) darwin target support by peterlodri-sec · Pull Request #577 · ravynsoft/ravynos

peterlodri-sec · 2026-08-06T05:20:31Z

Closes the first ARM64 build blocker on Apple Silicon macOS hosts (issue #575): clang targeting arm64 defines __aarch64__/__arm64__, neither handled in TargetConditionals.h, so every compile falls through to #error unrecognized GNU C compiler.

Changes

TargetConditionals.h (toolchain + runtime + SDK copies): add TARGET_CPU_ARM64 define, an __arm64__/__aarch64__ branch (64-bit, little-endian), and wire into the TARGET_RT_64_BIT chain
dtrace_ctf/libctf/qsort.c: guard qsort_r redefinition against macOS libc
xar/Makefile: Darwin Homebrew openssl@3 include/lib paths
CoreServices/Makefile + CoreFoundation/GNUMakefile: honor NO_ROOT (no chown root:wheel on unprivileged host builds)
Docs/BUILDING.md: document bmake -j8 NO_ROOT=1 world for macOS hosts

Verification

TargetConditionals.h compiles + runs standalone for arm64-apple-darwin (TARGET_CPU_ARM64=1, TARGET_RT_64_BIT=1, little-endian) and x86_64 (no regression). Produced via the entheai fan-out (agy coders, coder.vaked.dev free tier).

Closes the first ARM64 build blocker on Apple Silicon macOS hosts (issue ravynsoft#575): clang targeting arm64 defines __aarch64__/__arm64__, neither of which was handled, so every compile fell through to '#error unrecognized GNU C compiler'. - TargetConditionals.h (toolchain, runtime, SDK): add TARGET_CPU_ARM64 define + __arm64__/__aarch64__ branch (64-bit, little-endian), wire into TARGET_RT_64_BIT chain - dtrace_ctf/libctf/qsort.c: guard qsort_r redefinition against macOS libc - xar/Makefile: Darwin openssl@3 include/lib paths (Homebrew) - CoreServices/Makefile + CoreFoundation/GNUMakefile: honor NO_ROOT (don't chown root:wheel on user builds) - Docs/BUILDING.md: document bmake -j8 NO_ROOT=1 world on macOS hosts Verified: TargetConditionals.h compiles + runs on arm64-apple-darwin (TARGET_CPU_ARM64=1, TARGET_RT_64_BIT=1, little-endian) and x86_64 (no regression). Produced via the entheai fanout (agy coders).

peterlodri-sec · 2026-08-06T06:00:17Z

any Q?

dreamer-120 · 2026-08-06T06:06:41Z

One question. Why do you keep submitting the same AI slop contribution that (iirc) got rejected once before? Granted, you are the same person who made continuous strange comments in the discord server, sending strange links, endorsing AI slop, and even sending a bizarre random curl command, yes?
Do you hold such little joy in your life that, in order to seemingly accrue entertainment, you burden small open source projects with the annoyance of having to deal with your cogsucking self?
Are you so devoid of the foundational creativity and desire to build that defines us as a species that you have to do everything through a soulless machine?
I look forward to seeing your answers, Peter, though I hope you can write them without the assistance of AI.

jqackkk · 2026-08-06T07:02:09Z

One question. Why do you keep submitting the same AI slop contribution that (iirc) got rejected once before? Granted, you are the same person who made continuous strange comments in the discord server, sending strange links, endorsing AI slop, and even sending a bizarre random curl command, yes? Do you hold such little joy in your life that, in order to seemingly accrue entertainment, you burden small open source projects with the annoyance of having to deal with your cogsucking self? Are you so devoid of the foundational creativity and desire to build that defines us as a species that you have to do everything through a soulless machine? I look forward to seeing your answers, Peter, though I hope you can write them without the assistance of AI.

Clock it 👍

ashifolfi · 2026-08-06T14:56:29Z

One question. Why do you keep submitting the same AI slop contribution that (iirc) got rejected once before?

I dont think(?) This is the same exact pull request.

However one thing that does confuse/concern me is the seeming hard-coded dependency on specifically a homebrew installed version of openssl??

mszoek · 2026-08-06T16:18:20Z

Let's keep review comments to the purely technical. Whether this is AI generated or not, it's mostly updates to #defines in TargetConditionals.h and looks very low risk. There's no generated code that might be stolen. However... there are a couple of issues that have to be fixed before I can merge it. See review comments.

mszoek · 2026-08-06T16:19:18Z

 DMIHelper: ${.CURDIR}/DMIHelper.c
 	mkdir -p ${BUILDROOT}/System/Library/CoreServices
 	$(CC) -o ${BUILDROOT}/System/Library/CoreServices/DMIHelper ${.CURDIR}/DMIHelper.c
+.if !defined(NO_ROOT) || !${NO_ROOT}


I don't think the || !${NO_ROOT} is needed here. We only need to test if the variable is defined.

@mszoek The || !{NO_ROOT} makes sense to allow IDEs like Xcode or Build tools like Make to set -DNO_ROOT=0 to force this sort of bypass (more deliberate and intentional than -UNO_ROOT)

I think this is a best practice.

So either the whole guard is unnecessary or the || makes sense here

@mszoek The || !{NO_ROOT} makes sense to allow IDEs like Xcode or Build tools like Make to set -DNO_ROOT=0 to force this sort of bypass (more deliberate and intentional than -UNO_ROOT)

NO_ROOT is an internal variable that is managed by the build scripts. You should never need to set it manually, and should not do so.

I think this is a best practice.

In general it is.

So either the whole guard is unnecessary or the || makes sense here

The guard is necessary to prevent EPERM errors from the chown and chmod when uid is not 0. Whether the additional test for non-zero is necessary is debatable, and I disagree that it is.

Nothing ever defines NO_ROOT unless the build should not do chown/chmod steps. You should never have to use -UNO_ROOT or any definition of NO_ROOT, whether 1 or 0. It's meant to be driven from an "is uid == 0?" check at the top level, not a manual input.

Additionally, there are several other references to NO_ROOT that would have to be updated as well to include the extra non-zero check. Not worth the squeeze IMHO. Revisit if it becomes a problem later.

mszoek · 2026-08-06T16:21:35Z

 	}
 }

+#if !defined(__APPLE__)


Careful. The presence of macro __APPLE__ does not mean aarch64 or even macOS since ravynOS (and PureDarwin, I think) both also define __APPLE__. This will break the Linux host build and probably the future ravynOS host build.

Let's find a way to make this a weak symbol that will be overridden by libraries if it exists during link.

Indeed it does - PD, so this applies to other Darwin distros

Isn't there still a __arm__ and a __RAVYNOS__ somewhere? How lightweight are those defs can they be usedhere? Or only after the low level build?

It would be possible right now to use #if !__RAVYNOS__ && __APPLE__ because the host compiler on macOS won't define our macro, but that will break the instant the build is self-hosted.

The root cause seems to be that macOS defines a qsort function that Linux does not. It might be better to move the qsort implementation here into a different source file and only include it in the build when "${.MAKE.OS}" == "Linux" or something along those lines.

mszoek · 2026-08-06T16:30:31Z

+.elif "${.MAKE.OS}" == "Darwin"
+CFLAGS += -I/opt/homebrew/opt/openssl@3/include -I/usr/local/opt/openssl@3/include
+LDFLAGS += -L/opt/homebrew/opt/openssl@3/lib -L/usr/local/opt/openssl@3/lib
 .endif


This is also problematic. OS Darwin will be detected when building on ravynOS, and the /opt/homebrew path will not be valid there yet.

Shouldn't we be using corecrypto or CommonCrypto on a Darwin platform? I'm unclear on why it would need openssl.

Under the Linux path, it uses OpenSSL.
Under Darwin, it uses CoreCrypto.
See https://github.com/apple-oss-distributions/xar/blob/main/xar/xar.spec.in#L12 and https://github.com/apple-oss-distributions/xar/blob/main/xar/lib/hash.c#L48

mszoek · 2026-08-06T16:32:08Z

+ifneq ($(NO_ROOT),1)
 	/usr/sbin/chown -RH -f root:wheel $(DSTBASE)/CoreFoundation.framework
+endif


We shouldn't need this: the GNUmakefile isn't used in our build. Why is it here?

Good question: why? (This looks to be about cross compilation no?)

Well.. GNUmakefile is here because it's part of the CoreFoundation sources and I didn't remove it 🤣. It isn't used by the ravynOS build and can be deleted.

mszoek requested changes Aug 6, 2026

View reviewed changes

Uh oh!

Conversation

peterlodri-sec commented Aug 6, 2026

Changes

Verification

Uh oh!

peterlodri-sec commented Aug 6, 2026

Uh oh!

dreamer-120 commented Aug 6, 2026

Uh oh!

jqackkk commented Aug 6, 2026

Uh oh!

ashifolfi commented Aug 6, 2026

Uh oh!

mszoek commented Aug 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vali0004 Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Vali0004 Aug 6, 2026 •

edited

Loading