Add C ABI - #63
Open
colemancda wants to merge 30 commits into
Open
Conversation
colemancda
force-pushed
the
feature/c-abi
branch
from
August 1, 2026 16:26
3990938 to
6db3296
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Scaffolding for a drop-in, Swift-implemented replacement for BlueZ's shared
libbluetooth.so.3. The deliverable is a library that loads, resolves all 218 symbols the reference exports, and fails loudly (by symbol name) on any call not implemented yet — so the rest of the port can proceed incrementally, one symbol family at a time.Nothing in the
bluezpackage actually links this shared library —bluetoothd,bluetoothctl,btmon,hciconfigandsdptoolall statically linklibbluetooth-internal.a— so replacing it can't break the Bluetooth stack itself; it exists solely for third-party consumers.Sources/CBluetoothLinuxABIvendors the eleven public BlueZ headers verbatim (GPL-2.0-or-later, isolated in its own directory with its own LICENSE and README) and generates a stub for every symbol not yet implemented, viascripts/gen_stubs.py. Each stub's signature is read out of the vendored headers, so it's checked against the real declaration rather than hand-typed.scripts/symbols.txtrecords the reference export surface (218, split 17/101/100 acrossbluetooth.c/hci.c/sdp.c);scripts/implemented.txtrecords the 27 currently implemented (thebluetooth.c+bt_uuid_*families, implemented in PureSwift/Bluetooth).scripts/gen_symbols.pyderives the linker version script and the flat export list from these;scripts/check-exports.shasserts the built library against it.scripts/ownership.mdrecords the return/who-frees/lifetime contract for each symbol, ahead of implementation — the conventions aren't uniform (some allocate on the heap, some write into a caller buffer, some return static pointers) and guessing produces leaks or double frees no type checker would catch.CMakeLists.txtbuildslibbluetooth.so.3.19.15by linking aPureSwift/Bluetoothcheckout's static archives (-DBLUETOOTH_PACKAGE_PATH) together with the generated stubs, with the soname, version, and a pinned export list that Package.swift can't express.Conformance/README.mdrecords where the differential conformance harness for the implemented symbols lives (in PureSwift/Bluetooth, alongside the symbols it covers) and what's needed for the rest.Verified
check-exportstarget).libbluetooth.so.3, aside from three already-documentedbt_compidtostrnaming deltas.hci_open_dev) aborts withlibbluetooth (PureSwift): hci_open_dev is not implemented yet.rather than crashing unhelpfully or corrupting state.Test plan
swift build— default configuration, unaffectedSWIFTPM_BLUETOOTH_CABI=1 swift build— C ABI target buildscmake -B build -G Ninja -DBLUETOOTH_PACKAGE_PATH=<Bluetooth checkout> && cmake --build build—libbluetooth.so.3.19.15buildscmake --build build --target check-exports— 228/228 symbols match