Xcode 27 usuwa ld64 i wymaga unikalnych nazw modułów

Apple wycofało linker jednym zdaniem: „Linker ld64 został usunięty, a opcja -ld_classic nie jest już obsługiwana.”¹ Flaga, która właśnie zniknęła, to flaga, której dodanie Apple samo zalecało. W informacjach o wydaniu Xcode 15 -Wl,-ld_classic figurowało jako obejście dwóch błędów linkera.³

TL;DR

• Xcode 27 usuwa ld64. W finalnym toolchainie -ld_classic jest ignorowane z ostrzeżeniem, a linkowanie kończy się kodem wyjścia 0, natomiast drugi zapis, który Apple kiedyś udokumentowało, -ld64, powoduje niepowodzenie linkowania.¹¹² Notatki Apple do Xcode 15 zalecały tę flagę przy awariach związanych ze słabymi symbolami i przy błędach importu w LTO, Xcode 16 oznaczył ją jako przestarzałą, a Xcode 26 nie powiedział o niej ani słowa.³⁴¹⁰
• Drugie pęknięcie tkwi w kompilatorze Swift. Apple uczyniło skanowanie zależności jedną wspólną operacją, więc „każdy moduł Clang osiągalny z pojedynczej operacji skanowania zależności Swift musi mieć unikalną nazwę.”² Apple asekuruje się dwukrotnie: skanowanie „może zgłosić błąd”, a wcześniej skaner „mógł tolerować powtarzające się nazwy.”²
• Oba ujawniają się przy aktualizacji toolchaina, a nie przy zmianie deployment targetu czy wyborze SDK, i żadne nie ma komponentu w środowisku wykonawczym. Narażona populacja: dostarczone binaria, CocoaPods albo duża, mieszana baza kodu Swift/Objective-C/C++.
• To „może” u Apple nie jest ostrożnością redakcyjną. Na Xcode 26.6 umieściłem na jednej ścieżce wyszukiwania dwie mapy modułów deklarujące tę samą nazwę i uruchomiłem skaner 20 razy: dziewięć przebiegów zakończyło się awarią SIGSEGV, pięć przerwaniem, a sześć powodzeniem.⁸ Na finalnym toolchainie 20 przebiegów na tym samym wejściu za każdym razem wypisuje błąd redefinicji i za każdym razem kończy się kodem wyjścia 0, podczas gdy dostarczona mapa modułów z następnego punktu nie wypisuje niczego; szczegóły zawiera druga aktualizacja z 15 września.¹³
• Dostarczona mapa modułu redeklarująca moduł z SDK — przypadek, który Apple wymienia z nazwy — kompiluje się dziś po cichu i przesłania prawdziwy moduł. Moja podkładka SQLite3 przeszła typecheck z kodem wyjścia 0, a sqlite3_open przestało istnieć.⁸
• W siedmiu przeanalizowanych projektach: zero -ld_classic, OTHER_LDFLAGS nigdzie nieustawione i zero zduplikowanych nazw modułów wśród 391 map modułów — bo żadne repozytorium nie zawiera mapy pisanej ręcznie.⁹

Obie notatki trafiły najpierw do informacji o wydaniu Xcode 27 beta 4, obok Swift 6.4 i SDK z cyklu 27, i obie pozostały bez zmian w informacjach o wydaniu finalnym z 14 września.¹¹¹²

Aktualizacja, 15 września: co finalny toolchain robi z każdą z flag

Xcode 27 (27A266a) ukazał się 14 września, a zawarty w nim linker rozstrzyga pytanie, którego ten artykuł nie mógł sprawdzić w lipcu. xcrun ld -v zgłasza teraz:¹²

@(#)PROGRAM:ld PROJECT:ld-27037.1
BUILD 21:17:51 Aug 25 2026
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main
LTO support using: LLVM version 21.0.0 (static support for 30, runtime is 30)

Wiersz „will use ld-classic for:”, który wypisywał Xcode 26.6, zniknął, a wraz z nim plik binarny ld-classic: w usr/bin toolchainu jest jeden linker, ld. Dwa zapisy, które w lipcu trafiały w tę samą ścieżkę kodu, teraz się rozchodzą. Z tym samym jednowierszowym hello.c:¹²

xcrun clang hello.c -o hello -Wl,-ld_classic

ld: warning: -ld_classic is no longer supported and will be ignored

Kod wyjścia zero, plik binarny się linkuje. Następnie:

xcrun clang hello.c -o hello -Wl,-ld64

ld: library 'd64' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Kod wyjścia jeden, brak pliku binarnego. Nowy linker nie rozpoznaje już -ld64 jako przełącznika wyboru linkera, więc czyta go jako -l d64, czyli żądanie biblioteki o nazwie d64, i zawodzi, bo takiej nie ma. Lipcowe zdanie „przestaje akceptować -ld_classic” było więc prawdziwe w połowie: flaga, którą Apple wymienia, jest tolerowana z ostrzeżeniem, a flaga, którą Apple wymieniło w Xcode 15, -ld64, jest tą, która psuje kompilację. Projekt z -Wl,-ld64 w OTHER_LDFLAGS po aktualizacji zawodzi z komunikatem błędu, który ani razu nie wspomina o linkerze; projekt z -Wl,-ld_classic buduje się dalej i dostaje ostrzeżenie przy każdym linkowaniu. Wpis o premierze Xcode 27 zestawia obie flagi z pozostałymi zmianami, które odpalają się przy aktualizacji.

Aktualizacja, 15 września: skaner z finalnego toolchainu na tych samych dwóch kolizjach

Poniższe eksperymenty z mapami modułów przeprowadziłem w lipcu na Xcode 26.6. Na 27A266a, z tymi samymi dwoma katalogami deklarującymi module Widget na jednej ścieżce wyszukiwania, swiftc -typecheck nadal zawodzi w 20 przebiegach na 20 z error: redefinition of module 'Widget' i notą previously defined here, więc kompilacja nadal się zatrzymuje. Zmienił się skaner. swiftc -scan-dependencies na tym samym wejściu kończy się kodem 0 we wszystkich 20 przebiegach, we wszystkich 20 wypisuje na stderr identyczny błąd redefinition of module 'Widget' wraz z notą i we wszystkich 20 zapisuje kompletny graf zależności, który rozwiązuje Widget do mapy modułu z pierwszego katalogu -I. Tam, gdzie Xcode 26.6 dziewięć razy kończył się awarią, a pięć razy przerwaniem, skaner z finalnego toolchainu za każdym razem zgłasza kolizję i mimo to kończy pracę. Lipcowy odczyt „może” u Apple, jako asekuracji wobec niestabilnego skanera, na finalnym toolchainie się nie broni.⁸¹³ Na finalnym toolchainie skaner wypisuje błąd i kończy się kodem 0, co oznacza, że krok budowania, który kieruje się tym kodem wyjścia, widzi udane skanowanie, a niepowodzenie przychodzi krok później, przy kompilacji. Nie sprawdzałem, jak własny system budowania Xcode traktuje wypisany błąd ze skanowania zakończonego kodem zero.¹³

Przypadek z dostarczoną mapą pozostaje cichy. Vendor/module.modulemap redeklarujący SQLite3 na ścieżce wyszukiwania skanuje się z kodem wyjścia 0 i niczym na stderr, w 20 przebiegach na 20, a graf rozwiązuje SQLite3 do dostarczonej mapy, a nie do usr/include/SQLite3.modulemap z SDK, czyli pliku, do którego linia 7 w usr/include/module.modulemap odsyła jako extern module SQLite3 "SQLite3.modulemap"; plik importujący ten moduł przechodzi typecheck czysto, a plik wywołujący sqlite3_open nadal zawodzi z error: cannot find 'sqlite3_open' in scope, dopóki dostarczony katalog nie opuści ścieżki wyszukiwania. Na finalnym toolchainie drugi z kształtów, które Apple wymienia z nazwy, nie daje żadnej diagnostyki, która nazywałaby tę kolizję.¹³

Flaga, którą Apple kazało dodać

Historia zaczyna się od napisania linkera od nowa. Xcode 15 ogłosił nowy linker, uczynił go domyślnym „dla wszystkich binariów macOS, iOS, tvOS i visionOS” i w jednym zdaniu podrzędnym ustalił warunki wycofania poprzednika: „O klasyczny linker nadal można poprosić jawnie za pomocą -ld64; zostanie on usunięty w przyszłym wydaniu.”³

Nowy linker przyszedł z błędami, a Apple udokumentowało wyjście awaryjne dwukrotnie na tej samej stronie. Pierwszy wpis w Known Issues: „Binaria używające symboli ze słabą definicją ulegają awarii w czasie działania na iOS 14/macOS 12 lub starszych. Dotyczy to przede wszystkim projektów C++ ze względu na intensywne wykorzystanie słabych symboli.” Obejściem proponowanym przez Apple było podniesienie deployment targetu „albo dodanie -Wl,-ld_classic do ustawienia kompilacji OTHER_LDFLAGS.”³ Drugi, dotyczący plików obiektowych LTO, które linkowały słabe importy symboli jako niesłabe, oferował w tym samym ustawieniu „-Wl,-weak_reference_mismatches,weak lub -Wl,-ld_classic.”³

Oba błędy najmocniej uderzały w projekty C++ i to tłumaczy, kto nadal nosi tę flagę. Nikt nie wraca do ustawienia, które zatrzymało awarię.

Xcode 16 uprzedził jednym zdaniem: „Opcja linkera -ld_classic jest przestarzała i zostanie usunięta w przyszłym wydaniu.”⁴ Potem cisza. Przeszukałem informacje o wydaniu Xcode 26 pod kątem ld_classic, ld64 i klasycznego linkera — nie ma tam nic.¹⁰

Obecny toolchain wciąż akceptuje flagę i wciąż na nią narzeka. Na Xcode 26.6 zlinkowałem z nią trywialny program w C:⁷

xcrun clang hello.c -o hello -Wl,-ld_classic

ld: warning: -ld_classic is deprecated and will be removed in a future release

Kod wyjścia zero. Plik binarny się linkuje. Podstawienie -Wl,-ld64 daje identyczne ostrzeżenie z nazwą -ld_classic, więc oba zapisy, których Apple używało, trafiają dziś w tę samą ścieżkę kodu.⁷ Notatka Apple do Xcode 27 wymienia wyłącznie -ld_classic. W finalnym toolchainie oba zapisy się rozchodzą, jak pokazuje aktualizacja powyżej: -ld_classic jest ignorowane z ostrzeżeniem, a -ld64 powoduje niepowodzenie linkowania.¹²

Jeden szczegół komplikuje słowo „usunięty”. Linker z Xcode 26.6, poproszony o przedstawienie się przez xcrun ld -v, raportuje, które architektury deleguje dalej:⁷

@(#)PROGRAM:ld PROJECT:ld-1267
BUILD 16:38:58 Jun  8 2026
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main
will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em

ld-classic istnieje w toolchainie jako prawdziwe binarium, z własną stroną man, a linker nadal kieruje do niego osiem architektur.⁷ Żadna z nich nie przetrwała w aktualnym SDK dla aplikacji: iPhoneOS 26.5 deklaruje wyłącznie arm64e i arm64, a SDK watchOS dokłada arm64_32.⁷ Ta lista to 32-bitowe ARM-y, i386 oraz wbudowane cele Cortex-M. Odczytanie ich nieobecności w SDK jako powodu, dla którego usunięcie jest bezpieczne dla twórców aplikacji, to mój wniosek, a nie twierdzenie Apple.

Jak znaleźć flagę, nie ufając grepowi

-ld_classic mieszka w OTHER_LDFLAGS, więc zamiast przeszukiwać pliki pod kątem tekstu, warto zapytać system budowania, do czego to ustawienie się rozwija:

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "OTHER_LDFLAGS|SUPPORTED_PLATFORMS"

W projekcie Reps wraca jedna linia:⁹

    SUPPORTED_PLATFORMS = appletvos appletvsimulator iphoneos iphonesimulator macosx

OTHER_LDFLAGS nie pojawia się wcale i to właśnie jest odpowiedź: ustawienie nie ma żadnej wartości, więc nie trafiają z niego do etapu linkowania żadne flagi. Nieobecność w rozwiniętych ustawieniach kompilacji niesie informację, której nieobecność w wyszukiwaniu tekstowym nie niesie. Pytanie o platformy również warto rozstrzygać przez SUPPORTED_PLATFORMS, nigdy przez *_DEPLOYMENT_TARGET, które Xcode zapisuje niezależnie od tego, czy dany cel jest realny.

W trakcie audytu trzy pułapki dały fałszywie czyste wyniki, a każda z nich nic nie wypisuje i kończy się powodzeniem. timeout nie istnieje w standardowym macOS, więc opakowanie w niego xcodebuild zwraca kod 127 i puste wyjście, które czyta się jak projekt bez żadnych flag linkera. W zsh nieujęte w cudzysłów --include=*.pbxproj zostaje rozwinięte przez globbing, zanim zobaczy je grep, więc polecenie umiera z „no matches found” zamiast zaraportować zero trafień. A find nie podąża za dowiązaniem symbolicznym podanym jako punkt startowy, co ma znaczenie, bo xcrun --sdk iphoneos --show-sdk-path zwraca właśnie dowiązanie: find "$SDK" -name '*.modulemap' nie znajduje nic, podczas gdy find -H "$SDK" znajduje 266 plików.⁹ Wzorce trzeba ujmować w cudzysłów, przekazywać -H i upewnić się, że polecenie trafia w coś, o czym wiadomo, że tam jest, zanim zaufa się zeru.

Ręcznie utrzymywany target trzyma flagę w project.pbxproj albo w .xcconfig; projekt CocoaPods może ją dostać także z punktu zaczepienia post_install, którego nie odnotowuje żaden plik edytowany przez programistę. Flota, którą audytowałem, nie ma ani jednego, ani drugiego, więc ta ostatnia ścieżka pozostała niesprawdzona.⁹

Reguła unikalnych nazw modułów i dwa zastrzeżenia Apple

Drugie pęknięcie przychodzi w przebraniu zysku wydajnościowego, wpisane do New Features, a nie do Deprecations. Wpis Apple w sekcji Swift Compiler, w całości:

Skaner zależności Swift został zoptymalizowany tak, by unikać zbędnej pracy konfiguracyjnej i zbędnego wyszukiwania nagłówków przy odnajdywaniu modułów Clang w ramach jednej operacji skanowania zależności, co istotnie poprawia wydajność skanowania. W konsekwencji tej zmiany każdy moduł Clang osiągalny z pojedynczej operacji skanowania zależności Swift musi mieć unikalną nazwę. Jeżeli dwie mapy modułów widoczne dla tego samego skanowania deklarują moduł Clang o tej samej nazwie, skanowanie może zgłosić błąd. Wcześniej skaner mógł tolerować powtarzające się nazwy. Najczęstsze przypadki to projekty lub SDK, które udostępniają tę samą nazwę modułu Clang z więcej niż jednej lokalizacji na ścieżce wyszukiwania nagłówków, oraz dostarczane źródła firm trzecich, które zawierają module.modulemap redeklarujący moduł z SDK.²

Cztery rzeczy warto tu rozdzielić. Apple ogranicza wymóg do tego, co osiągalne w ramach jednego skanowania, a nie do całego dysku. Konsekwencję formułuje jako „może zgłosić błąd” i tak samo asekuruje opis dawnego zachowania. Wymienia z nazwy dwa kształty wyzwalające problem: jedną nazwę modułu udostępnianą z dwóch lokalizacji na ścieżce wyszukiwania nagłówków oraz dostarczony module.modulemap redeklarujący moduł z SDK. Wyzwalaczem jest zaś toolchain, skoro nic w tym wpisie nie odwołuje się do deployment targetu ani do wersji SDK.

Sama reguła jest starsza od optymalizacji. Język map modułów Clanga stawia sprawę wprost: „Każdy moduł musi mieć pojedynczą definicję.”⁶ Dokumentacja nigdzie nie mówi, co się dzieje po złamaniu tej reguły, a to milczenie okazuje się w pełni zasłużone: odpowiedzią toolchaina nie jest jedno zachowanie, lecz kilka.

Co faktycznie robi kolizja

Zastrzeżenia Apple sprawiły, że chciałem tę awarię zobaczyć, więc zbudowałem jej najmniejszą wersję: dwa katalogi, w każdym module.modulemap deklarujący ten sam moduł.⁸

A/module.modulemap    B/module.modulemap
module Widget {       module Widget {
    header "widget.h"     header "widget.h"
    export *              export *
}                     }

Gdy oba katalogi znajdą się na ścieżce wyszukiwania, zwykły typecheck zawodzi za każdym razem tak samo, w 20 przebiegach na 20:⁸

B/module.modulemap:1:8: error: redefinition of module 'Widget'
1 | module Widget {
  |        `- error: redefinition of module 'Widget'
A/module.modulemap:1:8: note: previously defined here

redefinition of module to ciąg, którego należy szukać w logu kompilacji — clang z Xcode 26.6 już go wypisuje. Usunięcie jednej ścieżki wyszukiwania sprawia, że ta sama kompilacja się udaje, co potwierdza, że wyzwalaczem jest widoczność w obrębie jednej kompilacji, a nie obecność na dysku.⁸

Skaner zależności zachowuje się inaczej i w lipcu właśnie ta różnica wyglądała na cały powód, dla którego Apple napisało „może”; druga aktualizacja z 15 września wraca do tej kwestii. Przepuszczenie tych samych dwóch map modułów przez swiftc -scan-dependencies 20 razy dało trzy wyniki: dziewięć awarii z SIGSEGV, pięć przerwań i sześć czystych powodzeń.⁸ Ślady stosu z przebiegów zakończonych awarią prowadzą przez performParallelClangModuleLookup, co pasuje do wyścigu w równoległym wyszukiwaniu, którego wymianę Apple opisuje. Przypisanie tego niedeterminizmu właśnie takiemu wyścigowi to mój odczyt śladu, a nie twierdzenie Apple.

Drugi przypadek wymieniony przez Apple jest tym cichym. Napisałem mapę modułu taką, jaką dostarcza zależność zewnętrzna — deklarującą SQLite3, prawdziwy moduł w SDK iPhoneOS — umieściłem ją na ścieżce wyszukiwania i skompilowałem względem niej kod:⁸

Vendor/module.modulemap
module SQLite3 {
    header "shim.h"
    export *
}

Kompilacja się powiodła. Kod wyjścia 0, żadnego ostrzeżenia, żadnej noty, żadnej diagnostyki jakiegokolwiek rodzaju. Potem poprosiłem tę samą konfigurację o sqlite3_open:⁸

error: cannot find 'sqlite3_open' in scope

Bez dostarczonego katalogu na ścieżce wyszukiwania identyczny plik kompiluje się bez problemu. Dostarczona mapa modułu całkowicie przesłoniła SQLite3 z SDK, a toolchain nie powiedział ani słowa. Dziś zatem przypadek redeklaracji w dostarczonych źródłach nie zawodzi głośno — zawodzi jako brakujące API w module, który rzekomo został zaimportowany. Notatka Apple mówi, że skanowanie w Xcode 27 „może zgłosić błąd”, co zamieniłoby ciche przesłonięcie w błąd kompilacji.

Buduję na Xcode 26.6 (build 17F113), więc każda powyższa diagnostyka pochodzi z poprzedniego toolchaina.⁷⁸ Nie mogę podać treści błędu z Xcode 27 i żadnej nie wymyśliłem. Maszyneria diagnostyczna, ciąg do wyszukania i tolerancja, której wycofanie Apple opisuje, istnieją już dziś. (15 września: ten akapit, a także przewidywanie zamykające powyższy akapit, opisują lipiec; na finalnym toolchainie przypadek z dostarczoną mapą nadal zawodzi po cichu, a wyjście dla obu kształtów znajduje się w drugiej aktualizacji na początku tego wpisu.¹³)

Audyt zduplikowanych nazw modułów

Wyliczenie zadeklarowanych nazw modułów wygląda na jednolinijkowego grepa, ale dwie konstrukcje języka map modułów dają błędne odpowiedzi.

extern module Foo "Foo.modulemap" to odwołanie zapowiadające, a nie definicja, a SDK Apple używa 79 takich odwołań w jednej mapie modułów.⁷ Naiwne skanowanie liczy odwołanie i prawdziwą definicję jako dwie deklaracje Foo. Po drugie, module Darwin.C { ... } używa kropkowanego identyfikatora modułu, żeby rozszerzyć moduł zadeklarowany gdzie indziej; 13 map modułów z SDK otwiera module Darwin.something, a odczytanie pierwszego członu jako deklaracji najwyższego poziomu wrzuca całą trzynastkę do jednego worka z prawdziwą deklaracją Darwin jako kolizję obejmującą 14 plików.⁷ Oba fałszywe alarmy pojawiły się w moim pierwszym podejściu.

Wersja, która przetrwała, radzi sobie z komentarzami, z głębokością nawiasów klamrowych (dzięki czemu zagnieżdżone podmoduły explicit module zostają poza wynikiem) oraz ze ścieżkami zawierającymi spacje:

find -H "${1:-.}" \( -name '*.modulemap' -o -name 'module.map' \) \
  -not -path '*/build/*' -not -path '*/.build/*' \
  -not -path '*/DerivedData*/*' -print0 |
while IFS= read -r -d '' map; do
  awk -v f="$map" '
    { line = $0; sub(/\/\/.*/, "", line)
      if (depth == 0 && line !~ /extern[[:space:]]+module/ &&
          match(line, /(^|[[:space:]])module[[:space:]]+[A-Za-z_][A-Za-z0-9_.]*/)) {
        n = substr(line, RSTART, RLENGTH); sub(/.*module[[:space:]]+/, "", n)
        if (n !~ /\./) print n "\t" f
      }
      for (i = 1; i <= length(line); i++) {
        c = substr(line, i, 1)
        if (c == "{") depth++; else if (c == "}") depth--
      }
    }' "$map"
done | sort -u > /tmp/modnames.txt

cut -f1 /tmp/modnames.txt | uniq -d | while read -r n; do
  echo "duplicate: $n"
  awk -F'\t' -v n="$n" '$1==n {print "  " $2}' /tmp/modnames.txt
done

Najmocniejszą dostępną kontrolą negatywną jest własny SDK Apple, który musi spełniać tę regułę, żeby toolchain w ogóle działał. Skierowane na SDK iPhoneOS 26.5 polecenie znajduje 1099 deklaracji najwyższego poziomu w usr/include i 205 w mapach modułów frameworków — w obu przypadkach zero duplikatów.⁷ Skierowane na dane testowe zbudowane tak, by kolidowały, wskazuje duplikat i oba pliki.⁸

Wykluczenia mają swoją wagę. -not -path '*/build/*' nie wyklucza .build/, bo wzorzec potrzebuje dosłownej nazwy katalogu, a SwiftPM zapisuje wygenerowane mapy modułów do .build tuzinami. Pozostawienie .build dało jedyne „duplikaty” w siedmiu projektach: GrappleCore w sześciu plikach i GrappleRender w trzech, wszystkie będące wyjściem SwiftPM, obejmujące dwa targety Swift w różnych katalogach kompilacji.⁹ Ta dziewiątka nie jest nawet identyczna bajt po bajcie, a powód jest pouczający: każdy plik opakowuje tę samą nazwę modułu wokół bezwzględnej ścieżki do wygenerowanego nagłówka we własnym katalogu kompilacji, więc różnią się jednym ciągiem znaków i niczym, co ma znaczenie. Audyt, który nazywa je kolizjami, wyczerpuje swoją wiarygodność, zanim dotrze do czegokolwiek prawdziwego.

Xcode produkuje ten sam fałszywy alarm w sposób jeszcze mniej dwuznaczny. W obrębie jednego drzewa DerivedData zapisuje wygenerowaną mapę modułu każdego pakietu Swift dwukrotnie — do GeneratedModuleMaps-iphonesimulator/ oraz do plików pośrednich samego targetu — za każdym razem ze względną ścieżką nagłówka. W drzewie jednego projektu 15 nazw pojawia się po dwa razy, a wszystkie 15 par jest identycznych bajt po bajcie.⁹ Audyt należy zawęzić do źródeł, nie do wyjścia kompilacji.

Co zawiera siedem projektów

Oba audyty przepuściłem przez siedem projektów Xcode na Xcode 26.6. Uczciwym wynikiem jest czyste zero.⁹

OTHER_LDFLAGS jest nieustawione we wszystkich siedmiu projektach, w całej flocie nie ma nigdzie pliku .xcconfig, nie ma też CocoaPods, Carthage ani dostarczonych .framework czy .xcframework.⁹ Audyt nazw modułów objął 391 map modułów — 204 w katalogach projektów i 187 we współdzielonym DerivedData, gdzie lądują kompilacje z GUI Xcode — i każda z nich jest wyjściem kompilacji.⁹ Ani jedno repozytorium nie zawiera ręcznie napisanej mapy modułu.

Oba zera mają tę samą przyczynę i to właśnie ten wniosek warto zabrać ze sobą: narażoną populacją są projekty mieszające języki programowania, a te takie nie są. W 463 plikach Swift flota nie ma ani jednego źródła Objective-C, C++ czy C — jedynym skompilowanym kodem spoza Swifta są dwa shadery Metal w projekcie Water.⁹ Zerowy wynik z bazy kodu, która nigdy nie była zagrożona, jest słabym dowodem na temat samych zagrożeń, a mocnym na temat tego, kto powinien przeprowadzić audyt.

Dwa szczegóły znaczą więcej niż same zera. Jedyne ręcznie pisane mapy modułów w rozwiązanych pakietach należą do swift-crypto, które udostępnia cztery podkładki w C o nazwach CCryptoBoringSSL, CCryptoBoringSSLShims, CXKCP i CXKCPShims — wszystkie różne.⁹ Żadna nazwa deklarowana przez flotę nie pojawia się też nigdzie w przestrzeni nazw modułów Clang z SDK, co sprawdzono wobec wszystkich 1318 nazw najwyższego poziomu, jakie polecenie znajduje w SDK iPhoneOS 26.5.⁹ Nie trafiają nawet te generyczne, przychodzące przez Supabase: SDK deklaruje moduły Clang o nazwach Foundation, UIKit i SQLite3, a żadnego o nazwie Crypto, Storage czy Auth.

Próg deployment targetu dla C++, który przesuwa się pod spodem

Jedna sąsiadująca zmiana uderza w te same projekty C++, które trzymają -ld_classic. Apple podniosło próg i wymieniło przy tym tylko jedną platformę — macOS: „Minimalny obsługiwany deployment target na macOS dla biblioteki standardowej C++ został podniesiony do 11.0.”⁵

Ten sam wpis oferuje wyjście awaryjne i w następnym zdaniu datuje jego usunięcie. libc++ zmieniło wynik lower_bound i upper_bound na std::map oraz std::set dla komparatorów niebędących ścisłym porządkiem słabym, a zdefiniowanie _LIBCPP_ENABLE_LEGACY_TREE_LOWER_UPPER_BOUND „przywróci historyczną implementację tych operacji”. A dalej: „To wyjście awaryjne zostanie usunięte w jednym z nadchodzących wydań (prawdopodobnie w kolejnym).”⁵ Powiązana zmiana sprawia, że multimap::find i multiset::find nie muszą już zwracać pierwszego równego elementu — zachowanie, o którym Apple pisze, że „nigdy nie było gwarantowane przez Standard”, choć libc++ zawsze je zapewniało — i wchodzi w życie bez możliwości rezygnacji.⁵ Makro warto traktować jak zgłoszenie migracyjne, a nie jak poprawkę.

FAQ

Dlaczego mój projekt zawiera -ld_classic?

Niemal na pewno dlatego, że zalecały ją informacje o wydaniu Xcode 15 od Apple. Dwa wpisy Known Issues zalecały tam dodanie -Wl,-ld_classic do OTHER_LDFLAGS: jeden dotyczył binariów używających słabo zdefiniowanych symboli, które ulegały awarii w czasie działania na iOS 14 i macOS 12 lub starszych — co, jak zaznaczyło Apple, „dotyczy przede wszystkim projektów C++” — a drugi plików obiektowych LTO linkujących słabe importy symboli jako niesłabe.³ Apple oznaczyło opcję jako przestarzałą w Xcode 16, a w Xcode 27 usunęło stojący za nią linker.¹⁴ Jeśli flaga tam jest, przed szukaniem zamiennika warto potwierdzić, że pierwotny błąd nadal się odtwarza.

Jak znaleźć zduplikowane nazwy modułów Clang w projekcie?

Należy wyliczyć deklaracje modułów najwyższego poziomu we wszystkich mapach modułów, poszukać nazwy występującej w dwóch plikach i usunąć z wyników katalogi kompilacji. Trzy rzeczy sprawiają, że to więcej niż grep: extern module Foo "path" jest odwołaniem, a nie definicją; module Foo.Bar rozszerza moduł zadeklarowany gdzie indziej, zamiast deklarować Foo; a zagnieżdżone podmoduły explicit module nie kolidują z nazwami najwyższego poziomu.⁶ .build, build i DerivedData trzeba wykluczyć jawnie, bo -not -path '*/build/*' nie łapie .build, a zarówno SwiftPM, jak i Xcode rutynowo duplikują generowane mapy modułów.⁹

Jak wygląda ten błąd w Xcode 27?

Na Xcode 27.0 (27A266a) treść jest ta sama, którą Xcode 26.6 już wypisuje: error: redefinition of module 'Widget' wraz z note: previously defined here. Zwykły -typecheck wypisuje ją i kończy się kodem 1; -scan-dependencies wypisuje ją i kończy się kodem 0.¹³ W lipcu na moim komputerze działał Xcode 26.6 (build 17F113), więc lipcowy tekst nie raportował żadnego wyjścia z Xcode 27;⁷⁸ dodaje je druga aktualizacja z 15 września na początku wpisu.¹³ Apple pisze o Xcode 27, że skanowanie „może zgłosić błąd”, więc w logach warto szukać redefinition of module, a nie ciągu, który ktoś zgadł.

Czy awaria związana z unikalnością nazw modułów zależy od deployment targetu?

Nie. Apple formułuje ten wymóg wobec pojedynczej operacji skanowania zależności Swift i nie wymienia we wpisie żadnej wersji systemu, żadnego SDK ani deployment targetu.² Zmiana w linkerze czyta się tak samo — jako usunięcie z toolchaina.¹ Oba trafiają w pierwszą kompilację w Xcode 27, razem z makrem @State, a nie razem z wymogami z tego samego cyklu wyzwalanymi przez SDK.

Najważniejsze wnioski

Dla twórców aplikacji na iOS: - Zamiast szukać -ld_classic grepem, warto odpytać OTHER_LDFLAGS przez xcodebuild -showBuildSettings -configuration Release -sdk iphoneos. Nieobecność w rozwiniętych ustawieniach oznacza, że ustawienie nie ma żadnej wartości; nieobecność w wyszukiwaniu tekstowym nie oznacza nic.⁹ - W logach kompilacji należy szukać redefinition of module — diagnostyki, którą Xcode 26.6 już wypisuje — a nie zmyślonej treści błędu z Xcode 27.⁸

Dla zespołów z dostarczanymi zależnościami C lub C++: - Dostarczone pliki module.modulemap warto najpierw sprawdzić wobec przestrzeni nazw SDK: Apple wymienia ten przypadek z nazwy, a dziś zawodzi on po cichu. Moja dostarczona podkładka SQLite3 skompilowała się z kodem wyjścia 0 i sprawiła, że sqlite3_open zniknęło.⁸ - Audyt należy zawęzić do źródeł i wykluczyć .build, build oraz DerivedData. Każdy pozorny duplikat wśród 391 map modułów okazał się wygenerowanym wyjściem kompilacji dla pojedynczego targetu Swift.⁹

Dla osób odpowiedzialnych za wydania: - Obie zmiany warto traktować jako wyzwalane przez toolchain i zaplanować na pierwszą kompilację w Xcode 27, a nie na migrację SDK. Żadna nie odwołuje się do deployment targetu ani nie ma komponentu w środowisku wykonawczym.¹² - Zastrzeżenia Apple warto zachować w zgłoszeniu. Skanowanie „może zgłosić błąd”, a 20 przebiegów jednej kolizji na Xcode 26.6 dało trzy różne wyniki — jedna udana kompilacja nie dowodzi więc niczego.²⁸ Na finalnym toolchainie skanowanie wypisuje błąd, ale kończy się kodem 0, więc zielony krok skanowania również niczego nie dowodzi.¹³

Cykl 27 zawodzi wciąż w innych miejscach: klucz ekranu startowego zatrzymuje wysyłkę do sklepu, obowiązkowy cykl życia sceny zatrzymuje uruchomienie aplikacji, a makro @State zatrzymuje kompilację na poziomie kodu źródłowego. Usunięcie linkera i reguła unikalnych nazw modułów zatrzymują ją warstwę niżej — w tych częściach toolchaina, których nikt nie konfiguruje celowo. Centrum całej serii to Seria Ekosystem Apple.

Źródła