ICU audit for freebsd-launchd-mach superseded

Decision-quality survey of ICU usage across every Apple-source repo relevant to the launchd-adjacent system-services stack we're building on FreeBSD. The question was: do we need to install ICU on the freebsd-launchd-mach ISO? The audit recommended no (Option A — drop ICU, patch the handful of CF files that use it). Execution proved the recommendation wrong; see the callout below and the libicu port plan for the actual outcome.

Companion to the launchctl CoreFoundation spike, which picked swift-corelibs-foundation as our CF source. That spike's §14.4 left the ICU question open ("install ICU as a build dep, keep all CF source files"); this audit was meant to revisit that decision with evidence and reverse it — but the evidence turned out to be incomplete.

The body below is preserved as the original audit, both as a record of how the wrong decision was reached and because the per-component inventory of CF-ICU usage (§5–§9) remains accurate and useful for future porting work. The "what we lose" caveats (§12) and "could we vendor Apple's ICU instead?" (§13) are the most relevant sections post-flip; everything before that was reasoning toward an answer that didn't survive contact with reality.

1. What is ICU?

ICU = International Components for Unicode, an IBM-originated C/C++ library (Apache 2.0 + ICU License) that provides industrial-grade Unicode + localization support. It's the de-facto standard backend for everything <language, region, calendar, encoding>-aware on Linux, macOS, Windows, Android, FreeBSD, and the Java/.NET runtimes. On FreeBSD it's installable via the icu port; the libraries land at /usr/local/lib/libicu{uc,i18n,data}.so (~30 MB combined).

ICU exists because text processing is much harder than it looks once you leave ASCII:

• Locale data: how a Spanish user formats currency vs. a Japanese one. Region preferences for calendar (Gregorian, Buddhist, Hebrew, Islamic), measurement units, date order, decimal separator. The data tables for ~700 locales (CLDR — the Common Locale Data Repository) ship inside ICU as libicudata.so.
• Collation: ordering strings the way humans expect them in a particular language. "ä" sorts with "a" in German but as a distinct letter in Swedish. ICU's collation tables encode these rules per-locale.
• Normalization: Unicode allows the same character to be encoded multiple ways (precomposed "é" vs. "e" + combining acute). NFC/NFD/NFKC/NFKD normalization forms reconcile this. Required for reliable equality / hashing.
• Case mapping: ASCII case-folding is trivial; full Unicode case-folding (e.g., German sharp-s "ß" ↔ "SS") requires per-language rules.
• Date / time formatting: turning an absolute timestamp into a human-readable string in the user's locale (e.g., "Mar 15, 2026" vs. "15 marzo 2026" vs. "15. März 2026"). Requires the CLDR pattern templates.
• Number / currency formatting: "$1,234.56" in en_US, "1.234,56 €" in de_DE.
• Transliteration: converting between scripts ("Москва" → "Moskva", "東京" → "Tōkyō").
• Regular expressions: ICU implements a full Unicode-aware regex engine.
• Encoding converters: converting text between >200 character encodings (GB18030, Shift_JIS, EUC-KR, Big5, ISO-2022-JP, every legacy code page).

None of this is needed by C programs that handle ASCII reverse-DNS keys or UTF-8 file paths. It's the surface that human-facing apps care about — not the system-services lane.

1.1 Does FreeBSD base have ICU? What does it provide instead?

FreeBSD base does not ship ICU. Stock FreeBSD 15.0 has no libicuuc.so, libicui18n.so, or libicudata.so in /usr/lib or anywhere in the pkgbase install — ICU comes from the third-party ports tree as devel/icu (installed to /usr/local/lib if a port that needs it pulls it in). Nothing in FreeBSD's base system links ICU. The userland utilities (ls, sort, grep, etc.) do their locale-aware work without it.

What FreeBSD base does provide is the POSIX locale + NLS facilities in libc:

The practical effect: POSIX C programs that want "respect the user's locale" get most of what they need from libc. The Apple userland tools we surveyed in §7 (ls, sort, grep, etc.) call setlocale/strcoll/wcscoll/nl_langinfo — libc NLS — and work fine on FreeBSD without ICU.

What you give up by relying on libc NLS instead of ICU:

• No CLDR data. ICU ships ~700 locales' worth of CLDR; FreeBSD libc has whatever's in /usr/share/locale/ (usually a few dozen, lower fidelity).
• No Unicode Collation Algorithm with DUCET tailoring. POSIX collation is "load a table and compare byte-by-byte against it." ICU implements the Unicode Collation Algorithm (UCA) with locale tailoring — the same ordering Cocoa / Windows / Java use.
• No CFLocale-style query API. Cocoa apps ask "what's the currency symbol for the user's region?" via ICU; libc apps assemble that from nl_langinfo primitives.
• No non-Gregorian calendars. libc strftime is proleptic-Gregorian only. ICU supports Buddhist, Hebrew, Islamic, Japanese, Persian, ROC, and others.
• No Unicode-aware regex. libc <regex.h> is byte-oriented (works fine on UTF-8 if patterns avoid character-class ambiguity); ICU regex understands Unicode properties.
• No transliteration / normalization library. NFC/NFD/NFKC/NFKD and script-to-script transliteration are ICU territory.

For the launchd-adjacent system services: none of those gaps are felt. Service keys are ASCII reverse-DNS; plist contents are UTF-8 byte streams; timestamps are stored as absolute time intervals, not formatted for human display by the daemons themselves; encoding conversion is needed only for the niche cases the audit found and replaceable with libc strftime / strptime / iconv.

2. Which CoreFoundation APIs need ICU?

Our libCoreFoundation (swift-corelibs-foundation) routes specific CF APIs through ICU and falls back to in-tree fast paths for everything else. The map:

The dividing line: anything to do with presenting data to a human in their language belongs to the ICU side. Anything that operates on the structure of data (arrays, dictionaries, plists, byte streams, time intervals, run loops, sockets) is built-in.

3. Scope of this audit

Every Apple-source repo we've already vendored, plus every repo on the launchd-adjacent porting roadmap. 22 components total:

The GNUstep stack (libs-base, libs-corebase, libobjc2) is intentionally out of scope. GNUstep is the gershwin desktop overlay's lane; this ISO doesn't ship GNUstep. When gershwin lands later, ICU comes with it regardless (libs-base hard-requires ICU at build time) — but that's a separate decision in a separate buildlist.

4. Method — what we grepped for

Four parallel agents, one consistent toolkit, repo-by-repo:

1. Direct ICU usage: #include <unicode/...>, plus the prefixed-API families u_* (generic Unicode), ucol_* (collation), udat_* (date), unum_* (number), ureg_* (regex), unorm2_* (normalization), ucnv_* (encoding converters), uloc_* (locale), usearch_* (search).
2. CF-ICU API usage: every CF API from the table in §2 — CFLocale*, CFCalendar*, CFDateFormatter*, etc.
3. Locale-sensitive string compare: kCFCompareLocalized as a flag to CFStringCompareWithOptions.
4. Exotic encoding conversion: kCFStringEncodingGB*, kCFStringEncodingShiftJIS, kCFStringEncodingEUC_*, kCFStringEncodingBig5, kCFStringEncodingISO_2022*, etc. ASCII/UTF-8/UTF-16/Latin1 are free; anything else needs ICU's encoding tables.
5. Link-line evidence: Makefiles, xcconfigs, pbxproj scanned for -licu*, libicu*, libicucore, libicudata. Direct link is the unambiguous signal of runtime dependency.

5. Currently-vendored sources

What we already ship on the freebsd-launchd-mach ISO. The question is whether anything currently linked into the build pulls ICU.

6. Apple daemons (to port)

The six Apple-source daemons on the launchd-adjacent porting roadmap.

7. Apple userland-command repos

Five Apple-source command repos cloned locally as siblings of the daemon repos. Together they cover the userland CLI tools the project might want to port for parity with macOS.

8. Apple supporting frameworks & tools

Four more Apple OSS repos that the launchd-adjacent stack might link or transitively depend on. Audited for completeness so the decision rests on a closed set.

9. Summary matrix — all 22 components

Tally: 17 of 22 components are fully ICU-free with no work. 4 (configd, bootp, PowerManagement, IOKitUser) touch CF-ICU APIs in narrow paths totaling ~100 LOC across all four; each path has a direct libc-equivalent replacement. 1 (mDNSResponder) has direct-ICU code gated by an undefined macro. 1 (libCoreFoundation itself) ships ICU-using files we simply drop from SRCS.

10. Decision: don't install ICU superseded

Concrete changes in the libCoreFoundation Makefile — drop these files from SRCS:

CFLocale.c                CFLocaleIdentifier.c       CFLocaleKeys.c
CFCalendar.c              CFCalendar_Enumerate.c
CFDateFormatter.c         CFNumberFormatter.c
CFListFormatter.c         CFDateIntervalFormatter.c  CFRelativeDateTimeFormatter.c
CFStringTransform.c       CFRegularExpression.c
CFCharacterSet.c          CFStringEncodingDatabase.c CFICUConverters.c
CFApplicationPreferences.c

Add a Makefile comment naming the audit so a future maintainer who finds "why isn't CFLocale here?" gets the answer in one place.

11. Build-time vs runtime — what kind of dependency is ICU?

"Do we need ICU" splits into two questions, and the answer is different at each stage. Spelling it out so the consequences of the drop are unambiguous:

11.1 If we KEEP the ICU-using .c files in SRCS (the unstripped state)

11.2 If we DROP the 9 ICU-using .c files (the plan)

11.3 The footnote for the daemons we'll port later

configd / bootp (IPConfiguration) / PowerManagement / IOKitUser source code calls CF-ICU APIs (CFLocaleCreate, CFCalendar*, CFDateFormatter*, CFNumberFormatter*). Those calls resolve to symbols in libCoreFoundation. Since our libCoreFoundation doesn't export those symbols (we dropped the files), the daemon source has to be patched at port time to use libc replacements (strftime, strptime, localtime_r, direct CFStringCreateWithFormat). That's port-time source work, not an ICU dependency. Once patched, those daemons compile and run with zero ICU involvement at any stage.

Quantum: ~100 LOC of patches across four repos, one-shot per repo as we port them. Each patch is mechanical (replace a 5-line CFDateFormatter setup with a 1-line strftime call) and obvious from the audit citations in §6 and §8.

12. Caveats & what we lose

Honest accounting of the functionality the ISO won't have without ICU. These are real but small for our consumer set:

• No CFLocale / CFCalendar / CFDateFormatter / CFNumberFormatter: programs cannot format a date or number for human display. Stub each call site with libc strftime + ASCII templates when porting; output is en_US-shaped regardless of user locale. Cost: zero on system-daemon CLI output; cosmetic-only on user-facing tools like pmset.
• No CFStringTransform: no Unicode normalization (NFC/NFD), no transliteration. Not used by any audited component.
• No CFRegularExpression: CF's Unicode-aware regex is gone. Not used by any audited component. (Programs that want regex use libc <regex.h> directly.)
• No CFCharacterSet predefined sets: kCFCharacterSetWhitespace, kCFCharacterSetLetter, etc. become unavailable. Not used by any audited component — everything uses libc isspace/isalnum instead.
• No locale-sensitive CFStringCompare: kCFCompareLocalized won't behave correctly — comparisons fall back to binary order. Not requested by any audited component.
• No exotic encoding conversion: CFLite still supports UTF-8 / UTF-16 / ASCII / Latin1 / MacRoman natively. GB18030, Shift_JIS, EUC-KR, Big5 are gone. Not used by any audited component.
• No IDNA hostname normalization in mDNSResponder: international-domain-name hostnames advertised via mDNS would not be punycode-normalized. USE_LIBIDN is already off upstream; no real-world Bonjour traffic uses it.
• No PvD info expiration parsing in IPConfiguration (unless we add the 5-line strptime replacement). RFC 8801 is rarely deployed; carrier-provided DNS hint timestamps are advisory.
• Cosmetic timestamp formatting in configd debug logs and pmset CLI output: replaced with libc strftime in en_US shape.

None of this affects the core functionality of any system service on the ISO. The losses are entirely in the "make output prettier for the user's locale" category, which is the desktop concern, not the system-services concern.

Reversibility: every loss above is one Makefile line away from being restored. Install icu from FreeBSD pkg, add the dropped .c files back to SRCS, rebuild libCoreFoundation, re-link. No SONAME bump needed because the dropped files only add new symbols — binaries linking the no-ICU libCoreFoundation will just see NULL/missing-symbol behavior for those functions; binaries linking the with-ICU build see the full surface.

Future-proofing: if and when gershwin (the desktop overlay) lands on top of freebsd-launchd-mach, ICU comes along with libgnustep-base as its own hard build-time dependency (libs-base's configure.ac aborts without it). At that point the marginal cost of installing ICU is zero, and libCoreFoundation can be rebuilt with the full surface. The decision here is specifically about the standalone freebsd-launchd-mach ISO.

13. Could we vendor Apple's ICU instead? we did

Project pattern would suggest yes — we already vendor libdispatch, libxpc, launchd-842, libCoreFoundation, bootstrap_cmds from Apple-OSS or swiftlang in src/. ICU has an Apple fork too. So if we ever wanted ICU on this ISO, vendoring Apple's would be on-pattern. Worth knowing the cost.

13.1 Apple's ICU exists at apple-oss-distributions/ICU

Probed locally 2026-05-15. Shallow-clone summary:

13.2 The three options compared

13.3 What you'd give up vs. gain at each option

• Option A (drop): lose the rich-i18n CF surface (CFLocale / CFCalendar / etc.). System services unaffected. Gershwin desktop overlay, when it lands, installs ICU as libgnustep-base's build dep and brings the rich i18n surface back.
• Option B (FreeBSD pkg): keep the rich-i18n CF surface on this ISO. Add ~30 MiB. Take a pkg dependency on devel/icu. Zero project-side build complexity.
• Option C (vendor Apple's): keep the rich-i18n CF surface. Self-contained. Pay ~1M LOC + 221 MiB checkout in git history. Build complexity is real — Apple's build wants Xcode; FreeBSD-porting it is a non-trivial sub-project before launchctl can even compile. Most of the upstream ICU codebase has nothing to do with the CF integration we want.

13.4 Recommendation

The recommendation is "A unless something changes." If a future need surfaces (e.g., we decide to ship a Cocoa app on the bare freebsd-launchd-mach ISO without the full gershwin overlay), revisit. Option C remains the cleanest forward-compat answer if self-containment ever becomes a hard requirement (no FreeBSD-port chain).

13.5 The porting-tax math — what does Option A cost across the project lifetime?

Option A (drop ICU) does add a small per-port tax: every daemon that calls CF-ICU APIs needs ~5-40 LOC of mechanical patches at port time to replace those calls with libc equivalents. Worth pricing out explicitly.

What we save in return:

• ~30 MiB smaller ISO — no libicuuc.so / libicui18n.so / libicudata.so in /usr/lib. Dominated by the CLDR data tables in libicudata.
• No transitive pkg dependency on FreeBSD's devel/icu port. Matches the rest of the project's vendor-everything posture.
• Cleaner ldd on system daemons — no surprise ICU pulled in via libCoreFoundation.
• Slightly faster build — libCoreFoundation skips 9 source files (~30k LOC) and avoids resolving ICU headers / libs at compile / link time.

Per-port economics: a 30-90 minute mechanical-patch session per daemon, paid once at port time. With 4 known consumers totaling ~3-4 hours of work across the project lifetime, this is a small price for the savings. If a future port surfaces 200+ LOC of CF-ICU we'd treat that as a signal to flip and use Option B (FreeBSD pkg), not a reason to keep cycling through patches.

13.6 The trapdoor — flipping back is a four-change commit

If patch volume gets painful at some point, or a future port surfaces a CF-ICU dependency that's not mechanically replaceable, switching from Option A to Option B is:

1. Add icu to pkglist-base.txt (1 line).
2. Restore the 9 dropped .c files to libCoreFoundation's SRCS in src/libCoreFoundation/Makefile (1 Makefile section).
3. git revert the daemon CF-ICU patches (one revert commit per affected port that we already patched).
4. Rebuild — the libCoreFoundation SONAME stays the same; nothing else needs touching.

So Option A is not a one-way door — it's the "carry small patches while it's cheap to do so, flip if it stops being cheap" trade. The exit ramp stays open.

13.7 What also gets simpler if we drop ICU: buildpkgs.txt

The chroot's build-only package list (buildpkgs.txt) currently carries three packages that were there to support GNUstep's autotools build path: gmake, autoconf, libtool. With GNUstep out of scope on this ISO and ICU dropped, none of these have a remaining consumer:

So the drop-ICU decision drags along a clean-up of the build-pkg list as a free byproduct — three package installs the chroot doesn't need anymore.

14. Audit provenance

This consolidated report aggregates findings from four parallel audit passes performed 2026-05-15 against the local clones at /Users/jmaloney/Documents/launchd/. Method was identical across all four: ripgrep / awk / find over each repo, manual adjudication of grep hits, build-file scan for link-line evidence, false-positive filtering (notably the jq/decNumber and jq/oniguruma cases in text_cmds).

The four source audit documents are preserved verbatim in the working tree:

• /Users/jmaloney/Documents/launchd/icu_audit_current.md — vendored sources (7 components).
• /Users/jmaloney/Documents/launchd/icu_audit_apple_ports.md — daemon repos (6 components).
• /Users/jmaloney/Documents/launchd/icu_audit_user_cmds.md — command repos (5 components).
• /Users/jmaloney/Documents/launchd/icu_audit_extras.md — supporting frameworks & tools (4 components).

Each contains per-file line-number citations supporting the verdicts summarized above. Where a verdict in this consolidated report says "stub-replaceable" or "strftime-replaceable," the corresponding source audit document names the exact files and line ranges.

Written 2026-05-15 alongside the launchctl-corefoundation-spike's implementation phase. This audit reverses the spike's §14.4 tentative recommendation ("install ICU as a build dep") in favor of the no-ICU minimal build — the spike's text will be updated to match once this audit is reviewed and committed.