simdutf 現在已可在無需 libc++ 或 libc++abi 的情況下使用
自這個 PR 起，simdutf 已可在不需要 libc++ 或 libc++abi 的情況下使用1。
simdutf 是 libghostty-vt 中最後剩下的 libc++ 相依套件2。在更新 Ghostty 以使用這個新版 simdutf 建置後，我們得以從相依套件中完全移除 libc++ 與 libc++abi。
不依賴 libc++ 的好處
不依賴 libc++ 能讓函式庫更具可攜性（適用於嵌入式、WebAssembly、freestanding 環境）、簡化跨編譯（不需要針對特定目標的 C++ 標準函式庫）、縮小二進位檔大小，並可簡化靜態連結。
作為一個通用、低階的函式庫，simdutf 應該盡可能具備可攜性與彈性。如果下游使用者能輕鬆使用 libc++，那很好！但如果無法使用，也不應該因此被阻擋而無法使用 simdutf，畢竟它本質上並不需要它。
libc++ 與 libc++abi
要讓程式擺脫對 libc++ 的依賴，有兩個部分需要處理。
首先，libc++ 是 C++ 標準函式庫，提供了像是 std::vector、std::string 等內容。如果你引入了 <vector>，甚至是像 <cstring> 這種 libc 的 C++ 相容標頭，你就已經依賴了 libc++。
比較隱蔽的部分是 libc++abi，它提供了 C++ ABI(應用程式二進位介面)，包含例外處理、虛擬函式表、RTTI 等。如果你使用了任何需要這些機制的 C++ 功能，就算完全沒有引入任何 C++ 標準函式庫標頭，你仍然依賴著 libc++abi。
例如，以下這個最小化的 C++ 程式就依賴於 libc++abi，因為它使用了函式區域靜態變數，而這需要屬於 C++ ABI 一部分的執行緒安全初始化機制：
struct Implementation {
int version;
};
const Implementation& get_impl() {
static const Implementation impl{1};
return impl;
}
int main() {
return get_impl().version;
}讓 simdutf 擺脫對 libc++ 的依賴
我們先來談 libc++（而非 ABI）。
simdutf 是一個大量運用最新、最強大 C++ 功能的 C++ 函式庫，雖然我個人並不認識 Daniel Lemire（丹尼爾·勒米爾），但他似乎非常喜歡將 C++ 功能發揮到極致。因此，simdutf 在很大程度上就是一個 C++ 專案。
為了讓我的修改有機會被接受，我必須確保專案仍能繼續使用 C++ 功能，而不會造成困擾。
STL 用法
我決定採取的做法，是引入一個stl_compat.h 標頭檔，將所有 C++ 標準函式庫型別集中管理。在一般的 libc++ 模式下，stl_compat.h 中的所有內容都只是對應 C++ 標準函式庫型別的簡單引入或最小化別名，不會產生任何執行期開銷。
在 NO_LIBCXX 模式下，stl_compat.h 則針對 simdutf 會用到的 C++ 型別提供自身的實作，但僅實作到足以與 simdutf 所需功能相容的程度即可。舉例來說，stl_compat.h 提供了自己的 std::pair 實作。
因此，在整個 diff 中，所需的修改大多看起來像這樣：
-std::pair<const char *, char32_t *>
+internal::pair<const char *, char32_t *>
arm_convert_latin1_to_utf32(const char *buf, size_t len,
char32_t *utf32_output) {ABI 相容性
我的目標是盡可能保留 ABI 相容性。部分公開 ABI會暴露如 std::string 這類 C++ 型別，在這些情況下，就必須打破 ABI。除此之外，則完全保留。
考量到 SIMDUTF_NO_LIBCXX 是一項會對編譯單元造成變更的新功能，我認為僅在此旗標啟用時才打破 ABI 是可以接受的。在未啟用 NO_LIBCXX 旗標的現有情況下，ABI 會被完整保留，現有使用者更新 simdutf 時也不會遇到 ABI 中斷的問題。
令我驚喜的是，ABI 的中斷非常輕微，僅影響少數診斷用函式（例如用來取得作用中實作名稱的函式）以及用於處理其他 C++ 型別的輔助工具（例如文字編碼用的 std::string）。由於定義上，使用 SIMDUTF_NO_LIBCXX 的人本來就對 libc++ 沒有興趣，因此這些 ABI 中斷感覺更像是功能，而非缺陷。
讓 simdutf 擺脫對 libc++abi 的依賴
這項任務要複雜得多。
主要的問題在於，libc++abi 的相依性通常不會以明顯的原始碼層級引入形式出現。它們會出現，是因為編譯器會為了一些看似平常的語言功能，悄悄地產生對 C++ ABI 執行期環境的呼叫。為了偵測這些情況，我必須撰寫一個腳本來反編譯目的檔，並尋找像是 __cxa_guard_acquire 這類符號。
在 simdutf 中，最大的元兇是執行期分派層。原始程式碼大量依賴函式區域靜態變數。在 C++ 中，這些區域變數會由像是 __cxa_guard_acquire 與 __cxa_guard_release 這類執行緒安全初始化輔助函式來保護，而這些函式是由 C++ ABI 執行期環境所提供。因此，即使程式碼中完全沒有提到 libc++abi，編譯後的物件檔仍然依賴它。對此的修正方式，是在 NO_LIBCXX 模式下改用轉譯單元靜態變數，而非函式區域靜態變數。
#if SIMDUTF_IMPLEMENTATION_ICELAKE
#ifdef SIMDUTF_NO_LIBCXX
static const icelake::implementation icelake_singleton{};
#endif
static const icelake::implementation *get_icelake_singleton() {
#ifdef SIMDUTF_NO_LIBCXX
return &icelake_singleton;
#else
static const icelake::implementation icelake_singleton{};
return &icelake_singleton;
#endif
}
#endif接著，simdutf 將每個後端都建模為抽象 implementation 介面的子類別。這個設計可以保留，但抽象類別的虛擬函式表仍會為不可能被呼叫的純虛擬項目參照 __cxa_pure_virtual。在 SIMDUTF_NO_LIBCXX 模式下，我選擇提供一個極小的本地 shim，並確保執行期永遠不會實際執行到它。我將其標記為 weak，讓該符號在 C++ ABI 存在時可被覆寫。
#ifdef SIMDUTF_NO_LIBCXX
// The abstract implementation vtable still carries pure-virtual slots even
// though correct dispatch never reaches them in this build mode. Provide the
// narrowest possible ABI shim so stricter no-libcxx objects do not require
// libc++abi just for this unreachable hook. Keep it weak so a toolchain's real
// libc++abi definition wins if one is linked in anyway.
extern "C" SIMDUTF_WEAK [[noreturn]] void __cxa_pure_virtual() noexcept {
__builtin_trap();
}
#endif最後，我撰寫了一個腳本，在使用 -fno-exceptions 與 -fno-rtti 進行建置時進行稽核，並檢查是否完全沒有出現像是 __cxa_guard_*、__gxx_personality、__cxa_throw、typeinfo 或 __dynamic_cast 等符號。這已加入至 simdutf 的 CI 中，以確保未來在 NO_LIBCXX 建置中不會意外地重新引入對 libc++abi 的依賴。
驗證
內部
simdutf 是一個對正確性與效能要求極高的函式庫，因此我必須確保我的修改不會影響這兩者。我修改了現有的測試與基準測試套件，使其能在 NO_LIBCXX 與一般模式下執行，並確保所有測試皆通過且基準測試結果不受影響。
這件事的重要之處在於，我已提交必要的修改，以確保 NO_LIBCXX 模式能與現有的測試與基準測試套件相容。這意味著未來對 simdutf 的任何修改，都能持續對兩種模式進行驗證。
外部：Ghostty
接著，我將 Ghostty 更新為使用來自我 fork 的新版 simdutf，將我們的建置更新為使用 SIMDUTF_NO_LIBCXX，並加入了我們自己的測試套件，以驗證我們的產物不再依賴 libc++ 或 libc++abi。
Ghostty 擁有一套完整的測試，用於驗證我們的 UTF-8 解碼行為（特別是無效輸入的處理）。Ghostty 還有一個內建的基準測試套件，可在各種情境下測試我們的 UTF-8 吞吐量。我執行了所有 Ghostty 的測試與基準測試，並驗證它們全部通過，且如預期般 UTF-8 效能未受影響。
Pull Request
讓東西能運作，跟讓東西被合併，是兩件完全不同的事。
作為一名維護者，我太清楚「這能動」與「這可以被合併」之間的差距。我了解驗證他人工作並對未來的維護有信心的挑戰。我了解發起一個大型 PR 卻無法清楚說明為何要發起的困難。我也了解近期 AI 濫製內容所帶來的負擔。
因此，我投入了我期望一位頂尖貢獻者會付出的努力，並試著為 simdutf 的維護者成為那樣的人。
首先，我審閱了整個 diff（是的，全部約 3,000 行）。然後我又再審閱了一次。我親手將整個 diff 重讀了三到四遍。我根據那些即使功能上沒問題、但我自己可能會提出意見的地方，做了多處修改。
接著，我親手撰寫了一份詳細的 PR 說明，解釋了動機、做法、限制與驗證方式。我想確保維護者不僅了解細節，也能感受到我在細節上投入了多少思考。
最後，我揭露了我確實有使用 AI 來協助撰寫程式碼。但我也明確表示，我已手動審閱所有內容，在撰寫 PR 說明或留言時完全沒有使用 AI，並且作為一個人，我有能力也樂於為任何提議的修改進行辯護與調整。
諷刺的是，整理完整的 diff 大約只花了我 2 小時，但額外的驗證工作與 PR 準備卻花了約 3 小時。我在與人的互動層面上花的時間比寫程式本身還多，而出於對維護者投入心力的尊重，本就該如此。
最終狀態
simdutf PR 目前仍在審核中。初步回饋是正面的，我也樂於接受任何要求我進行的修改。維護者也有可能最終不願合併，這也沒關係。
如果你想在不使用 libc++ 或 libc++abi 的情況下使用 simdutf，目前可以先使用我的 fork。產生 amalgamated 單檔加標頭檔建置的相同指示仍然適用。在建置 C++ 並引入標頭檔時，只要確保定義了 SIMDUTF_NO_LIBCXX，即可取得無 libc++ 版本的函式庫。
Ghostty PR 現已合併。因此，libghostty-vt 在 SIMD 建置中已不再依賴 libc++ 或 libc++abi。