launchctl CoreFoundation spike

Picking the CoreFoundation source for the launchd-842 launchctl port. Apple's launchctl.c is 4,549 LOC of CF-heavy code. Three candidate implementations are on the table: gnustep/libs-base, gnustep/libs-corebase, and swiftlang/swift-corelibs-foundation. This spike audits each repo against the exact symbol set launchctl.c uses and produces a buy/build/skip decision per candidate, with a concrete porting plan for the winner.

Companion to the libxpc Foundation spike (which scoped Foundation at the project level) and the launchd-842 porting plan (which schedules launchctl as task I1e). This spike is narrower: it's specifically about which CF source launchctl.c compiles and links against on FreeBSD.

1. The problem — why pick CF now

The launchd daemon itself (/sbin/launchd, 235 KiB ELF) was the last big I1c milestone — it builds, links, execs, smoke-passes. Audit of the seven hand-written daemon TUs (launchd.c + core.c + runtime.c + ipc.c + log.c + kill2.c + ktrace.c) finds zero CoreFoundation calls: the daemon reads plists through the lower-level launch_data_t API in liblaunch. So nothing about the daemon depends on this decision.

The downstream consumer that does depend on it is launchctl (the user-facing CLI). support/launchctl.c in the launchd-842 vendor drop is 4,549 LOC, heavily plist-driven, and pulls in <CoreFoundation/CoreFoundation.h>, <CoreFoundation/CFPriv.h>, and <CoreFoundation/CFLogUtilities.h>. The default plan was "port launchctl after the GNUstep stack lands"; this spike re-examines that with actual symbol-level evidence.

2. What launchctl.c actually needs

Full audit at launchctl_api_audit.md in the working tree. Grep methodology in §12. Summary:

The 49 distinct CF function calls (CF functions + macros, deduped) are the gold-standard "does this CF source compile launchctl" checklist:

CFArrayAppendValue            CFArrayCreateCopy             CFArrayCreateMutable
CFArrayGetCount               CFArrayGetTypeID              CFArrayGetValueAtIndex
CFBooleanGetTypeID            CFBooleanGetValue
CFDataCreateWithBytesNoCopy   CFDataGetBytePtr              CFDataGetLength
CFDataGetTypeID
CFDictionaryAddValue          CFDictionaryApplyFunction     CFDictionaryCreateCopy
CFDictionaryCreateMutable     CFDictionaryGetCount          CFDictionaryGetKeysAndValues
CFDictionaryGetTypeID         CFDictionaryGetValue          CFDictionaryRemoveValue
CFDictionarySetValue
CFErrorCopyDescription
CFGetTypeID                   CFRelease                     CFRetain
CFNumberCompare               CFNumberCreate                CFNumberGetType
CFNumberGetTypeID             CFNumberGetValue
CFPropertyListCreateFromStream    CFPropertyListCreateFromXMLData
CFPropertyListCreateWithData      CFPropertyListCreateXMLData
CFRangeMake
CFReadStreamClose             CFReadStreamCopyError         CFReadStreamCreateWithFile
CFReadStreamOpen
CFSTR
CFStringCompareWithOptions    CFStringCreateWithBytes       CFStringCreateWithCString
CFStringCreateWithCStringNoCopy   CFStringGetCString        CFStringGetLength
CFStringGetTypeID
CFURLCreateDataAndPropertiesFromResource    CFURLCreateFromFileSystemRepresentation
CFURLWriteDataAndPropertiesToResource

The 25 kCF* constants are the standard set: kCFAllocatorDefault, kCFAllocatorNull, kCFAllocatorSystemDefault, kCFBooleanFalse, kCFBooleanTrue, kCFCompareEqualTo, the full kCFNumber*Type family (10 of them), kCFPropertyListImmutable, kCFPropertyListMutableContainersAndLeaves, kCFStringEncodingUTF8, kCFTypeArrayCallBacks, kCFTypeDictionaryKeyCallBacks, kCFTypeDictionaryValueCallBacks.

The 17 types are exactly the CF*Ref typedef set you'd expect (CFArrayRef, CFBooleanRef, CFDataRef, CFDictionaryRef, CFErrorRef, CFIndex, CFMutableArrayRef, CFMutableDictionaryRef, CFNumberRef, CFNumberType, CFPropertyListFormat, CFPropertyListRef, CFReadStreamRef, CFStringRef, CFTypeID, CFTypeRef, CFURLRef).

The one SPI symbol — _kCFSystemVersionBuildVersionKey from <CoreFoundation/CFPriv.h> — is referenced once at launchctl.c:4341 inside copySystemBuildVersion() to read /System/Library/CoreServices/SystemVersion.plist. It's literally CFSTR("ProductBuildVersion"). Even a CF source with no SPI surface can have this one constant pasted in.

3. gnustep/libs-base — audit

4. gnustep/libs-corebase — audit

5. swift-corelibs-foundation — audit

6. Side-by-side matrix

7. Decision

The matrix collapses to one viable answer. libs-base contributes nothing on the CF axis. libs-corebase has the right shape but the plist code paths are stubs — and plist parsing is launchctl's primary job. swift-corelibs-foundation's CF source carries the real Apple plist driver, ships the SPI surface launchctl-842 was written against, and stays under Apache 2.0.

The Swift-runtime entanglement is real but bounded: it's a knob (DEPLOYMENT_RUNTIME_SWIFT) the codebase still respects. We flip it, drop ICU-only sources, and write our own build target.

8. Porting plan for the winner

Concrete steps, ordered. Each step is a CI-checkpointable milestone.

8.1 Vendor

Copy Sources/CoreFoundation/ + Sources/CoreFoundation/include/ + Sources/CoreFoundation/internalInclude/ + uuid/ from ../swift-corelibs-foundation into src/libCoreFoundation/ in the freebsd-launchd-mach repo. Match the libdispatch precedent: vendored source, repo-local patches, no submodule.

8.2 Keep ICU files; install ICU as a build dep

Originally proposed: strip the nine ICU-consuming .c files (CFLocale*, CFCalendar, CFDateFormatter, CFNumberFormatter, CFStringTransform, CFRegularExpression, CFCharacterSet, CFStringEncodingDatabase, CFICUConverters). Revised after discussion: keep them, install ICU instead. Reasons:

• gershwin/libgnustep-base needs ICU anyway — it's already in our dep graph for the desktop track.
• configd / IPConfiguration / SystemConfiguration may transitively want CFLocale/CFCalendar/CFCharacterSet down the road. Keeping the files means we don't have to revert a stripping decision later.
• Less local divergence from upstream — future re-vendor drops are easier when our patch surface is small.

Build dep added: libicuuc + libicui18n + libicudata + their -dev headers (via FreeBSD devel/icu port or pkgbase if available). Add to buildpkgs.txt / pkglist.txt. Runtime cost on the ISO: ~30 MiB across the three libs.

The only subdir we still drop is src/libCoreFoundation/BlockRuntime/ — that's the WASI fallback for systems without a real libBlocksRuntime. We already ship /usr/lib/system/libBlocksRuntime.so via the libdispatch build (per the post-2026-05-13 bundling decision), so the upstream fallback is redundant.

8.3 Disable the Swift RC path

Patch internalInclude/CoreFoundation_Prefix.h:11 to set DEPLOYMENT_RUNTIME_SWIFT 0, or #undef + #define it explicitly. Confirm by inspection that CFRuntime.c's legacy bitfield-CAS path is now active and swift_retain/swift_release/__CFInitializeSwift/__CFSwiftGetBaseClass references are #else'd out.

8.4 Write a bsd.lib.mk Makefile

Single src/libCoreFoundation/Makefile following the precedent set by liblaunch, libsystem_kernel, libxpc:

• LIB=CoreFoundation
• SHLIB_MAJOR=6 (or whatever upstream uses; double-check)
• SRCS= the post-strip .c file list
• CFLAGS+= -DDEPLOYMENT_RUNTIME_C=1 -DDEPLOYMENT_TARGET_FREEBSD=1 -DCF_BUILDING_CF -fblocks -fconstant-cfstrings -I${.CURDIR}/include -I${.CURDIR}/internalInclude
• LDADD+= -ldispatch -lBlocksRuntime -lpthread
• Install to /usr/lib/system/libCoreFoundation.so.6 per the install-layout spike. Headers to /usr/include/CoreFoundation/.

8.5 Add build.sh step + smoke marker

Following the precedent of step 3i (libxpc) and 3m (liblaunch): a new build.sh step (call it 3p or wherever) that make -C src/libCoreFoundation's the lib, ldconfig-hints it (already covered by /etc/ld-elf.so.conf — /usr/lib/system is on it), and builds a tiny test_corefoundation.c at /usr/tests/freebsd-launchd-mach/test_corefoundation that round-trips a small dict through CFPropertyListCreateData + CFPropertyListCreateWithData in both XML and binary modes. Marker: COREFOUNDATION-OK. Expect grammar entry in tests/boot-test.sh.

8.6 Patch launchctl.c for the one missing symbol

Replace the single CFPropertyListCreateFromFile call (line ~526 vicinity per earlier audit) with a two-liner: CFReadStreamCreateWithFile + CFPropertyListCreateFromStream. Delete the unused #include <CoreFoundation/CFLogUtilities.h>.

8.7 Build launchctl

Mirrors the launchd daemon's Phase I1c flow: a src/launchd/support/Makefile using bsd.prog.mk, PROG=launchctl, SRCS=launchctl.c, BINDIR=/bin (per the install-layout spike — not /sbin; launchctl is on /bin). Link -lCoreFoundation -llaunch -lxpc -lsystem_kernel -lutil -lpthread. The non-CF shims (IOKit no-ops, NSSystemDirectories hand-roll, os/assumes.h reuse from the daemon build) live alongside.

8.8 LAUNCHCTL-BUILD-OK smoke marker

Boot-time /bin/launchctl help — the no-IPC CLI path, parallel to the LAUNCHD-BUILD-OK approach for the daemon. Expected output: the usage banner. Marker: LAUNCHCTL-BUILD-OK.

Estimated total effort

One to two engineer-days for steps 8.1–8.5 (the CF library), plus an unknown but bounded amount for 8.6–8.8 (the launchctl shims for the IOKit/NSSystemDirectories surface). The latter is at most a small .c file of stubs — smaller than what we already wrote for the launchd daemon's libsystem_kernel stubs.

9. Non-CF surface (IOKit, Mach-O, NSSystemDirectories)

Outside the CF question, launchctl.c pulls in three small macOS-only surfaces. None of the three CF candidates ships these — they're handled locally in the launchctl port:

9.1 IOKit (7 symbols, 2 call paths)

9.2 Mach-O (1 symbol)

getsectiondata, single call site at line 1717 inside GetPropertyListFromCache(), which is wrapped in #if TARGET_OS_EMBEDDED. We don't define TARGET_OS_EMBEDDED on FreeBSD; the whole code path drops out. The #include <mach-o/getsect.h> itself needs the same guard. Zero ELF-equivalent work needed.

9.3 <NSSystemDirectories.h> (9 symbols)

Sole consumer is load_and_unload_cmd() (lines 2631-2769) iterating /.../Library/LaunchAgents + LaunchDaemons per domain. Replace with a hand-rolled domain table:

static const struct {
    unsigned int mask;
    const char *path;
} _ns_dirs[] = {
    { NSUserDomainMask,    "~/Library" },
    { NSLocalDomainMask,   "/Local/Library" },   /* project policy: /Local replaces /Library */
    { NSNetworkDomainMask, "/Network/Library" },
    { NSSystemDomainMask,  "/System/Library" },
};

Plus a one-function reimplementation of NSStartSearchPathEnumeration / NSGetNextSearchPathEnumeration against that table. ~30 lines of C.

9.4 Other Apple-only headers (already handled by the daemon shims)

<os/assumes.h>, <libinfo.h>, <bootfiles.h>, the BSM auditd header — all of these already have shims in src/launchd/freebsd-shims/ from the I1c launchd-daemon build. They get reused as-is.

10. Coexistence with GNUstep — one CF per binary

Natural follow-up question, since gershwin already ships libgnustep-base and the GNUstep stack provides its own libgnustep-corebase with the same CF* API surface as the swift-corelibs CF we're recommending: do these two CoreFoundation implementations conflict if both are installed on the same system?

Answer: they coexist by design, provided no single binary links against both.

10.1 Why they don't conflict at the system level

Each CF runtime is a separately-named ELF shared library with its own SONAME and its own type registry:

Each binary's DT_NEEDED records exactly one of the two library names. ldconfig finding both shared objects in different directories is harmless — the dynamic linker resolves DT_NEEDED libCoreFoundation.so.6 by name and goes to /usr/lib/system/; it doesn't see libgnustep-corebase.so.0 at all. The two libraries can sit on the same disk indefinitely without anything bridging them.

10.2 Where the conflict WOULD happen (the rule)

CoreFoundation is a typed runtime, not just an API surface. CFArrayGetTypeID() returns a number that comes from the loaded CF's type-registry init — assigned at first call, different between the two implementations. A CFArrayRef created by one CF is just a pointer to an internal struct; the other CF doesn't recognize it as an array (its type ID is different), and CFRelease against the wrong runtime would either crash or corrupt refcounts. Same goes for the per-type vtables: each CF binds CFArrayCreate's function pointer at init time to its own copy of the implementation, and the two copies do not share any state.

So the project-wide rule:

10.3 Header paths matter too

If both libs ever installed headers to the same /usr/include/CoreFoundation/, second-install wins and every translation unit compiled after that point picks up the wrong types. Different header roots prevent it:

• swift-corelibs CF: /usr/include/CoreFoundation/{CoreFoundation,CFArray,CFDictionary,CFPropertyList,CFPriv,CFLogUtilities,…}.h — the canonical Apple-shape path.
• gnustep-corebase: whatever gershwin chose for the GNUstep tree. The GNUstep convention is typically a separate include root under /System/Library/Headers/ or $GNUSTEP_SYSTEM_HEADERS. As long as it's not /usr/include/CoreFoundation/, no conflict.

Both .pc files (if pkg-config is used) get distinct names — libCoreFoundation.pc vs libgnustep-corebase.pc. Consumers ask for one or the other explicitly.

10.4 What this means in practice for the launchctl port

The port is unaffected by the question of whether gershwin's CF stack is installed. launchctl links -lCoreFoundation from /usr/lib/system/ and compiles against headers from /usr/include/CoreFoundation/. It has no knowledge of gershwin's GNUstep stack and doesn't need to. Installing gershwin on the same system puts libgnustep-corebase.so.0 on disk in a different directory; the two CoreFoundations coexist without colliding at link time or at runtime.

This is the same posture gershwin already takes with libdispatch: gershwin ships libdispatch through its own pkg, and we ship our own libdispatch via /usr/lib/system/libdispatch.so. The two installations don't fight because each binary's link line picks one and the other is invisible to it.

11. Why not rewrite to GNUstep instead?

The obvious alternative: skip CoreFoundation entirely, rewrite each Apple system service we want to port (launchctl, configd, IPConfiguration, mDNSResponder, asl, …) to use GNUstep NSDictionary/NSArray/NSString in place of the CF equivalents. The project would then have one Foundation stack (GNUstep) for the entire userland.

This sounds clean. In practice it's worse than the swift-corelibs CF path by every meaningful axis. Four reasons:

11.1 CF is structural in these daemons, not decorative

For launchctl alone, CF is "the plist parser plus a few container helpers" — ~50 distinct functions per the audit. For the bigger Apple-source daemons further out on the roadmap, CF is the data model and the event model:

• IPConfiguration (Apple's DHCP/IPv6 client, ~10k LOC in apple-oss-distributions/bootp): CFDictionaryRef as the per-interface configuration state, CFArrayRef for lease history + DNS server lists, CFStringRef for every key passed to configd, CFRunLoopRef as the main event loop, CFRunLoopTimer for DHCP lease renewals + RFC 3315 timers, CFSocketRef for raw DHCP/DHCPv6 packet I/O. The daemon's overall shape is "configure a few CFRunLoopSources, enter CFRunLoopRun, never return." Rewriting that to NS is rewriting the daemon.
• configd: similar story. The SCDynamicStore is a CFDictionaryRef-backed cross-process store; the notification mechanism is CF-shaped. Plugin loading uses CFBundle/CFPlugIn.
• mDNSResponder: portable C core, with platform integration that pulls CF on Darwin (CFRunLoop, CFSocket, CFNetService advertisement). The Linux build of the same upstream avoids CF, so this one is the least CF-entangled — but the path of least resistance still uses the platform-Apple variant.
• asl: less CF-heavy, but the structured-logging API surface (asl_object_t) is CF-toll-free-bridged to CFTypeRef on Darwin.

"Strip CF and rewrite to NS" for IPConfiguration is a multi-month rewrite. For configd it's larger still.

11.2 configd's public API is CF-shaped

Even setting the daemon internals aside, configd exposes its surface as SystemConfiguration.framework — a CF-typed cross-process store API. Every Apple-source binary that asks the system "what's my hostname?" / "am I on a captive portal?" / "what are my network interfaces?" (and that's a lot of them: mDNSResponder, network setup helpers, security extensions, GUI network prefs equivalents) talks SystemConfiguration in CF terms.

Rewriting configd to use NS internally means rewriting the public API too, at which point every consumer of SystemConfiguration stops compiling against our fork. We'd be maintaining a divergent fork of every consumer for as long as the project exists. That's the spiral the libxpc plan explicitly warned against early.

11.3 The cost is asymmetric and one-way

The first row is engineering done once. The second row is engineering done forever, against a moving upstream target, with no path back to "just compile the official source" if the rewrite gets behind.

11.4 The scope_split memory anticipated exactly this case

The project's internal scope-split memo, written before this audit, says:

• GNUstep owns: libobjc2, Foundation, Base, GUI, Back, AppKit-equivalents — the framework/application layer.
• Apple source owns: Mach, launchd, configd, notifyd, asl, libdispatch, libxpc, liblaunch — the system-services layer.

swift-corelibs CF, deployed for system services only and never linked by apps (per §10's one-CF-per-binary rule), sits cleanly inside the Apple-source-system-services lane. It's the engine the daemons need; it's not a framework apps would link against. The split holds.

12. What this means for the GNUstep roadmap

The original plan was: port libobjc2 → tools-make → libs-base → libs-corebase, then launchctl. This spike says none of those are launchctl-blocking — and once we follow the reasoning in §11, none of them are configd-blocking, IPConfiguration-blocking, mDNSResponder-blocking, asl-blocking, or notifyd-blocking either. The Apple system-services layer is pure C with CF, by Apple's original design.

12.1 What the system services actually need from us

12.2 The reshaped Apple-source porting tree

The launchd-adjacent porting roadmap, post-swift-corelibs-CF decision:

libsystem_kernel + libdispatch + libxpc + liblaunch     [done — Phase A–I1b]
                              ↓
                       launchd daemon                   [done — Phase I1c]
                              ↓
              swift-corelibs CoreFoundation             [in flight, task #16–20]
                              ↓
                          launchctl                     [task #21–23]
                              ↓
              SystemConfiguration.framework             [later — configd's API surface]
                              ↓
                          configd                       [later]
                  ↓             ↓             ↓
            IPConfiguration  mDNSResponder   asl + notifyd  DiskArbitration

That whole tree is C-with-CF. GNUstep does not appear in it.

12.3 Where GNUstep is still on the roadmap (just not this roadmap)

1. The gershwin desktop / app side. Anything NS*-using — the AppKit-equivalent apps, GUI plumbing, app frameworks. Parallel track to the system services, not blocked by them and not blocking them.
2. CFPlugIn-loaded plugins for configd-class daemons. On Darwin, configd loads NetworkExtension / EAPOLController / EAP plugins that are Obj-C. Those plugins (not the daemon they plug into) would link GNUstep. Without them, the core daemons still run — we just lose plugin features. Defer until/unless we need them.
3. Future Apple-source binaries with NS surface. Spotlight, AppKit-using daemons, NSTask consumers. None of these are on the launchd-adjacent shortlist. If one shows up, GNUstep is the answer for the NS half — with the one-CF-per-binary discipline from §10.

12.4 Practical consequence: parallel tracks, not a sequential bottleneck

Before this audit the plan was "GNUstep block then Apple-services block," conceptually a single critical-path queue. After the audit, the picture is two independent tracks:

Apple-source system services:  libCoreFoundation → launchctl → configd → IPConf/mDNS/asl/…
                                                            (no GNUstep dep anywhere)

GNUstep / gershwin desktop:    libobjc2 → tools-make → libs-base → libs-corebase → apps
                                                            (no Apple-source-service dep)

If gershwin-developer already provides libobjc2 + libs-base (worth a single pkg search against the gershwin tree to confirm — the gershwin_provides memory confirms libdispatch is shipped; libobjc2/libs-base coverage TBD), the GNUstep track is largely "consume what's there." Either way, the two tracks run in parallel and don't block each other.

That's the headline take-away from this spike: you can ship a working FreeBSD with launchd + configd + IPConfiguration + mDNSResponder + asl + notifyd + DiskArbitration without ever building libobjc2 or libs-base, and then layer gershwin on top of that whenever the desktop work picks up.

13. Future: what if we want Swift on the ISO?

The choice to flip DEPLOYMENT_RUNTIME_SWIFT=0 in our libCoreFoundation raises a natural question: does that close the door on shipping Swift programs (or the Swift toolchain itself) on FreeBSD later? Short answer: no. Swift gets its own lane, just like GNUstep got its own lane, and the three coexist by the same one-CF-per-binary discipline established in §10.

13.1 What "Swift on the ISO" actually means in pieces

"Swift" splits into three things that are technically independent:

1. Swift toolchain — the swift / swiftc compiler + REPL + Foundation/XCTest for building Swift code on the system. FreeBSD has a swift-lang pkg.
2. Swift runtime — libswiftCore.so + friends, needed by any program written in Swift. Comes from the same toolchain.
3. Swift Foundation — swift-corelibs-foundation's Swift NS* classes layered over a Swift-RC-mode CF. Distributed as libFoundation.so (Swift) which on Linux/BSD statically embeds the Swift-mode CF C library inside itself. There's no upstream-shipped standalone libCoreFoundation.so in Swift mode — it's an internal static archive of the Swift Foundation build.

For Swift programs to work on the ISO we need (1) and (2) installable as a pkg. Item (3) ships with (1) when a Swift program imports Foundation.

13.2 Three lanes, three CoreFoundations, no collisions

Once Swift lands on the system, there are three CF implementations on disk:

The Swift Foundation's CF is statically linked into libFoundation.so — it doesn't export a libCoreFoundation.so file at all, so there's nothing for our SONAME to collide with. Apple's own macOS does the same trick: Swift's Foundation bundles a Swift-RC CF internally, separate from the system CoreFoundation.framework.

13.3 Why the lanes don't fight

The mechanism is identical to the GNUstep coexistence story in §10, just with one more lane:

• Each lane has its own SONAME (or, for Swift, no SONAME because CF is internal).
• Each binary's DT_NEEDED picks exactly one of the three: libCoreFoundation.so.6, libgnustep-corebase.so.0, or libFoundation.so.
• Each CF runtime has its own CFTypeID registry, vtable, and refcount allocator. A CFDictionaryRef created in one is unrecognizable to the others — but CF objects never cross process boundaries (only byte-stream representations like plists and XPC messages do), so that's not a real cross-process problem.
• The dynamic linker resolves each binary's DT_NEEDED by name, so even with all three libs on the system, no binary loads more than one.

13.4 Installing the Swift toolchain alongside our libCoreFoundation

Concrete picture for a future Swift-on-ISO sub-project:

• Add swift-lang (or build it from swiftlang/swift source) to the pkgbase / pkglist. Installs /usr/local/bin/swift + /usr/local/lib/swift/freebsd/libswiftCore.so + libFoundation.so etc.
• Per the no-/usr/local rule, the swift toolchain coming from a FreeBSD pkg lives at /usr/local/ as pkgs do — we don't relocate. Swift programs that link Foundation pick up libFoundation.so from there via the toolchain's rpath.
• Our /usr/lib/system/libCoreFoundation.so.6 is untouched. launchctl still resolves CFArrayCreate to our build; a hypothetical my-tool.swift resolves it to its toolchain's bundled Swift-mode CF (inside libFoundation.so) via Swift's import-resolution.
• ldconfig on a system with both installed is harmless — the libs have different file paths, different filenames, and the linker is name-driven.

13.5 The one combination that wouldn't work

A single binary that wants to be both an Apple-source-system-service (linking our libCoreFoundation) and a Swift program (linking Swift's libFoundation) is the one configuration that would break. Two CFs in one address space, two refcount conventions, two type registries — objects from one would crash when handed to the other.

This is a contrived combination — we don't ship anything that mixes those worlds — but the rule is the same as §10: one CF per binary, generalized now to three lanes. If a future use case forces "Swift code that needs to talk to a system service", the right answer is an RPC boundary (xpc / launchd / mach IPC), not double-linking.

13.6 Could we later switch our libCoreFoundation to Swift mode?

Technically yes — the DEPLOYMENT_RUNTIME_SWIFT macro is a build-time choice, and the legacy code path being #else'd not deleted means we could flip it back. But:

• Every binary linked against our libCoreFoundation would then transitively need libswiftCore.so at startup. That's dozens-of-MB of Swift runtime loaded into every launchctl / configd / IPConfiguration process. Defeats the original reason for picking non-Swift mode.
• Swift-mode CFTypeRefs are ABI-incompatible with non-Swift-mode ones. Flipping the macro is a one-way SONAME break — we'd need to bump to libCoreFoundation.so.7 and re-link every system service. Painful churn.
• There's no plausible benefit: our system-services consumers (launchctl, configd, …) are pure C and don't gain anything from Swift refcount. The only beneficiary would be a Swift program wanting to use our libCoreFoundation directly — and that program could just use Swift's bundled Foundation instead, which is the same upstream code with the Swift mode pre-baked.

So — flipping back is technically possible, practically pointless. The non-Swift choice is forward-compatible because Swift programs come with their own bundled CF anyway; we never need our build to be Swift-aware.

14. Impacts of these decisions — full accounting

This section lays out, decision by decision, what we're committing to (and what we're not) so the tradeoffs are visible before any of it lands as code. Six decisions feed this spike's plan, plus a closing audit of cross-cutting risks and what stays reversible.

14.1 Decision: swift-corelibs-foundation as the CF source

Alternatives rejected: libgnustep-corebase (plist parser stubs — fatal); libgnustep-base (zero CF C surface); rewrite every Apple system service to NS (multi-month, per-daemon, permanent fork — see §11).

14.2 Decision: DEPLOYMENT_RUNTIME_SWIFT=0 (no Swift refcount)

14.3 Decision: install at /usr/lib/system/libCoreFoundation.so.6

14.4 Decision: install ICU rather than strip CF's ICU-using files

14.5 Decision: drop src/libCoreFoundation/BlockRuntime/ subdir, use libdispatch's libBlocksRuntime

14.6 Decision: vendor at src/libCoreFoundation/, not as a submodule / external pkg

14.7 What we're NOT committing to

• GNUstep is not blocked. libobjc2, tools-make, libs-base, libs-corebase remain on the roadmap for the desktop side, on a parallel track that's not gated by anything in this spike.
• Swift on the ISO is not blocked. Per §13, Swift can land as its own lane with its own bundled CF; no conflict with our build.
• PID-1 launchd is a separate decision. The CF we're building today supports launchctl, and launchctl is independent of whether /sbin/launchd is PID 1 or a user-started daemon.
• The full Apple userland is not in scope. Only the launchd-adjacent system services (launchctl, configd, IPConfiguration, mDNSResponder, asl, notifyd, DiskArbitration). Other Apple-source (Spotlight, Quick Look, Network Extension framework, AppKit, Carbon) is explicitly out of scope.
• We are not committing to ship Apple's Foundation NSXxx classes. NSXxx-using consumers go through GNUstep libgnustep-base per the scope_split memory. swift-corelibs Foundation's Swift NS layer is not adopted.

14.8 Cross-cutting risks and mitigations

14.9 What's reversible vs. what's locked in

15. Open questions / follow-ups

1. Does gershwin-developer already provide libobjc2 / libs-base? If yes, the GNUstep work for later NS consumers reduces to "add to pkglist". One pkg search resolves it. (The gershwin_provides memory confirms it ships libdispatch; libobjc2/libs-base coverage is unconfirmed.)
2. SOVERSION for our libCoreFoundation.so: match Apple's libsystem_corefoundation? Or assign our own? Decide before consumers start linking against it.
3. Install path for the SPI headers: /usr/include/CoreFoundation/CFPriv.h — do we expose the SPI surface to all consumers or hide it? The launchctl source needs it; nothing else does today.
4. libCoreFoundation runtime deps: confirm at link time that the post-strip library actually only needs libdispatch + libBlocksRuntime + libpthread + libc. If any other transitive symbol surfaces, decide drop-the-file vs add-the-dep.
5. What if a future Apple-source binary wants more of CF than launchctl does (e.g. needs the CFLocale or CFCalendar surface)? Plan today is "drop the source files we don't use"; if we later need them back, undo the drop — the upstream is preserved verbatim.
6. Long-term: do we want both swift-corelibs CF and libs-corebase coexisting? The matrix shows they have non-overlapping strengths (libs-corebase covers CFBag/CFBitVector/CFTree/CFAttributedString that swift-corelibs doesn't carry as standalone). For launchctl, no. For project breadth, maybe. Side-by-side SOVERSION question similar to (2).

16. Methodology & audit provenance

This spike is grounded in three pieces of audit work done 2026-05-15 against the cloned repos at /Users/jmaloney/Documents/launchd/{libs-base,libs-corebase,swift-corelibs-foundation}. Methodology was uniform across all three: identify every CF* function definition (function body, not header decl — the gold standard), enumerate CF SPI surface, audit PropertyList implementation specifically, identify build-system entanglements.

Extraction patterns for the launchctl-side inventory (run against launchd-842/src/support/launchctl.c):

grep -oE 'CF[A-Z][A-Za-z0-9_]*' launchctl.c | sort -u    # CF identifiers
grep -oE 'k(CF|cf)[A-Za-z0-9_]*' launchctl.c | sort -u   # kCF constants
grep -oE '_CF[A-Za-z0-9_]*' launchctl.c | sort -u        # _CF SPI
grep -oE '\b_k[A-Za-z0-9_]*' launchctl.c | sort -u       # _k SPI constants
grep -oE 'IO[A-Z][A-Za-z0-9_]*' launchctl.c | sort -u    # IOKit
grep -oE 'k(IO|io)[A-Za-z0-9_]*' launchctl.c | sort -u   # kIO constants
grep -oE '\b(getsect[A-Za-z0-9_]*|getseg[A-Za-z0-9_]*)' launchctl.c | sort -u
grep -oE '\bNS[A-Za-z0-9_]*' launchctl.c | sort -u       # NS*

Junk filter: the IO[A-Z] and NS[A-Z] sweeps caught false-positive prefixes (IONARY, IORITY_REVISION from JETSAM_PRIORITY_REVISION, ION_AQUA, etc.). Hand-filtered to keep only real IOKit / NSSystemDirectories identifiers.

The 245-grep-count circulating earlier in the project's planning came from counting raw substring matches (every occurrence, including types and constants repeated across the file). The 49 number used in this spike is distinct function-call symbols, which is the meaningful unit for "does the CF source provide this?"

Raw audit documents (full per-symbol enumeration) are in the working tree:

• /Users/jmaloney/Documents/launchd/launchctl_api_audit.md
• /Users/jmaloney/Documents/launchd/libs-base_audit.md
• /Users/jmaloney/Documents/launchd/libs-corebase_audit.md
• /Users/jmaloney/Documents/launchd/swift-corelibs-foundation_audit.md

Spike written 2026-05-15 against launchd-842 vendor drop in freebsd-launchd-mach at commit 0fae6a1 (LAUNCHD-BUILD-OK green). Audits performed against repo clones the same day; HEADs noted in each candidate section. Companion documents: the libxpc Foundation spike (project-level Foundation scoping), the launchd-842 porting plan (which scheduled launchctl as task I1e), and the install-layout spike (which puts launchctl at /bin/launchctl).