Xcode 27でld64が削除され、モジュール名の一意性が必須に

Appleはリンカの引退を一文で告げました。「ld64リンカは削除され、-ld_classicオプションはサポートされなくなりました」¹。消えたこのフラグは、ほかならぬApple自身が開発者に追加せよと指示したフラグです。Xcode 15のリリースノートは、2件のリンカ不具合の回避策として-Wl,-ld_classicを提示していました³。

要点

• Xcode 27はld64を削除し、-ld_classicを受け付けなくなります¹。AppleはXcode 15のノートで、弱シンボル起因のクラッシュとLTOのインポート不具合に対してこのフラグを処方し、Xcode 16で非推奨とし、Xcode 26では何も述べませんでした³⁴¹⁰。
• 2つ目の破壊的変更はSwiftコンパイラ側にあります。Appleは依存関係スキャンを1つの共有アクションにまとめたため、「単一のSwift依存関係スキャンアクションから到達可能なすべてのClangモジュールは、一意のモジュール名を持たなければならない」ことになりました²。Appleは2度にわたって断定を避けています。スキャンは「エラーを報告する場合があります」、そして以前のスキャナは「名前の重複を許容していた場合があります」という書き方です²。
• どちらもデプロイメントターゲットやSDKの選択ではなくツールチェーンの更新で発火し、実行時の要素はありません。影響を受けるのは、ベンダー提供のバイナリ、CocoaPods、あるいはSwift/Objective-C/C++が混在する大規模コードベースを抱えたプロジェクトです。
• Appleの「場合があります」は編集上の慎重さではありません。Xcode 26.6で同一の名前を宣言する2つのモジュールマップを1つの検索パスに置き、スキャナを20回走らせたところ、9回はSIGSEGVでクラッシュ、5回はabort、6回は正常終了しました⁸。
• Appleが名指しするケース、つまりSDKのモジュールを再宣言するベンダー提供のモジュールマップは、現在のところ何も言わずにコンパイルが通り、本物のモジュールを覆い隠します。私が用意したSQLite3のベンダー版シムは終了コード0で型チェックを通過し、sqlite3_openは存在しないものになりました⁸。
• 監査した7プロジェクトの結果は、-ld_classicがゼロ、OTHER_LDFLAGSはどこでも未設定、391件のモジュールマップに重複名ゼロ。どのリポジトリにも手書きのモジュールマップが1つも無いからです⁹。

いずれの記載もXcode 27 beta 4のリリースノートに、Swift 6.4および27系SDKと並んで掲載されています¹¹。ベータ段階の文章として読んでください。

Appleが「追加せよ」と言ったフラグ

話はリンカの書き換えから始まります。Xcode 15は新しいリンカを発表し、「すべてのmacOS、iOS、tvOS、visionOSバイナリ」でこれを既定とし、引退の条件を一文で定めました。「クラシックリンカは-ld64で明示的に要求できますが、将来のリリースで削除されます」³。

新リンカにはバグがあり、Appleは同じページで2度、脱出口を文書化しました。1つ目のKnown Issueはこうです。「弱定義シンボルを使うバイナリは、iOS 14/macOS 12以前で実行時にクラッシュします。弱シンボルを多用するため、主にC++プロジェクトに影響します」。Appleが示した回避策は、デプロイメントターゲットを引き上げるか「OTHER_LDFLAGSビルド設定に-Wl,-ld_classicを追加する」ことでした³。2つ目は、LTOオブジェクトファイルが弱シンボルのインポートを非弱としてリンクしてしまう問題で、同じ設定に「-Wl,-weak_reference_mismatches,weakまたは-Wl,-ld_classic」を追加せよというものです³。

どちらの不具合もC++プロジェクトを最も強く直撃しました。今なおこのフラグを抱えているのが誰なのか、その理由はここにあります。クラッシュを止めた設定を、あとから見直す人はいないのです。

Xcode 16の予告も一文でした。「-ld_classicリンカオプションは非推奨であり、将来のリリースで削除されます」⁴。以降は沈黙です。Xcode 26のリリースノートをld_classic、ld64、クラシックリンカで検索しましたが、該当箇所はありませんでした¹⁰。

現行のツールチェーンは今もフラグを受け付け、今も苦情を言います。Xcode 26.6で、ごく単純なCプログラムをこのフラグ付きでリンクしてみました⁷。

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

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

終了ステータスはゼロ。バイナリはリンクされます。-Wl,-ld64に置き換えても-ld_classicを名指しする同一の警告が出るので、Appleが用いた2つの綴りは現時点で同じコードパスに到達しています⁷。AppleのXcode 27のノートが名指ししているのは-ld_classicだけであり、-ld64が同様に失敗するかどうかは検証できませんでした。

「削除」という語を一筋縄ではいかなくする事実が1つあります。Xcode 26.6のリンカにxcrun ld -vで素性を尋ねると、どのアーキテクチャを委譲しているかを教えてくれます⁷。

@(#)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はツールチェーン内に実体のあるバイナリとして存在し、独自のmanページも持っていて、リンカは今も8つのアーキテクチャをそこへ回しています⁷。ただし、現行のアプリ向けSDKに生き残っているものは1つもありません。iPhoneOS 26.5が宣言するのはarm64eとarm64のみ、watchOSのSDKがこれにarm64_32を加えるだけです⁷。委譲先の一覧は32ビットARM、i386、Cortex-M組み込みターゲットです。SDKに存在しないことをもって、アプリ開発者にとって今回の削除は安全だと読むのは、Appleの主張ではなく私の推論です。

grepに頼らずフラグを見つける

-ld_classicが住むのはOTHER_LDFLAGSです。ですからファイルを文字列検索するのではなく、ビルドシステムに最終的な解決値を尋ねましょう。

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

Repsプロジェクトに対して実行すると、返ってくるのは1行だけです⁹。

    SUPPORTED_PLATFORMS = appletvos appletvsimulator iphoneos iphonesimulator macosx

OTHER_LDFLAGSはまったく現れません。それこそが答えです。設定が未設定であり、そこからリンク段階に渡るリンカフラグは存在しないという意味になります。解決済みビルド設定における不在は、テキスト検索での不在が持ち得ない情報を持っているのです。プラットフォームの確認にもSUPPORTED_PLATFORMSを読んでください。*_DEPLOYMENT_TARGETは、対象が実在するかどうかに関係なくXcodeが書き込むので使えません。

監査中、偽の「クリーン」を生んだ罠が3つありました。いずれも何も出力せず、正常終了します。まずtimeoutは素のmacOSに存在しないため、xcodebuildをこれで包むと終了コード127と空の出力が返り、リンカフラグの無いプロジェクトのように見えてしまいます。次にzshでは、クォートしない--include=*.pbxprojがgrepに届く前にグロブ展開され、ヒット0件の報告ではなく「no matches found」でコマンドが死にます。そしてfindは、起点として与えられたシンボリックリンクを辿りません。これはxcrun --sdk iphoneos --show-sdk-pathが返すのがまさにシンボリックリンクだから重要になります。find "$SDK" -name '*.modulemap'は何も見つけませんが、find -H "$SDK"なら266件を見つけます⁹。パターンはクォートし、-Hを渡し、ゼロを信じる前に「そこにあると分かっているもの」にコマンドがヒットするか確かめてください。

手で管理しているターゲットなら、フラグはproject.pbxprojか.xcconfigに入っています。CocoaPodsプロジェクトの場合はpost_installフックから注入されることもあり、これは開発者が編集するどのファイルにも記録されません。私が監査した一群にはどちらも無いため、この最後の経路は未検証です⁹。

モジュール名ルールと、Appleの2つの留保

2つ目の破壊的変更は、性能改善という装いで、Deprecationsではなく新機能の項に収められています。AppleのSwiftコンパイラの項目は全文でこうです。

Swiftの依存関係スキャナは、単一の依存関係スキャンアクション中にClangモジュールを検索する際、冗長なセットアップ作業とヘッダ検索を回避するよう最適化され、スキャン性能が大幅に向上しました。この変更の結果として、単一のSwift依存関係スキャンアクションから到達可能なすべてのClangモジュールは、一意のモジュール名を持たなければなりません。同一のスキャンから見える2つのモジュールマップが同じ名前のClangモジュールを宣言している場合、スキャンはエラーを報告する場合があります。以前のスキャナは、名前の重複を許容していた場合があります。最も多いのは、ヘッダ検索パス上の複数の場所から同じClangモジュール名を提供しているプロジェクトやSDK、そしてSDKのモジュールを再宣言するmodule.modulemapを同梱するベンダー提供のサードパーティソースです。²

ここには切り分けるべきものが4つあります。まずAppleは要件の範囲を、ディスク全体ではなく1回のスキャンが到達できる範囲に限定しています。次に帰結を「エラーを報告する場合があります」と述べ、従来の挙動についても同じ調子で留保しています。さらに発火する2つの形を名指ししています。ヘッダ検索パス上の2箇所から提供される1つのモジュール名と、SDKのモジュールを再宣言するベンダー提供のmodule.modulemapです。そして引き金はツールチェーンです。デプロイメントターゲットにもSDKのバージョンにも一切言及がないからです。

ルール自体は最適化より前から存在します。Clangのモジュールマップ言語の仕様は端的にこう述べています。「各モジュールは単一の定義を持たなければならない」⁶。文書がついぞ述べていないのは、このルールを破ったときに何が起きるかです。そしてその沈黙には十分な理由がありました。ツールチェーンの答えは1つの挙動ではなく、複数だったのです。

衝突は実際に何を引き起こすか

Appleの留保を読んで、その失敗を自分の目で見たくなりました。そこで最小構成を組みました。ディレクトリを2つ用意し、それぞれに同じモジュールを宣言するmodule.modulemapを置きます⁸。

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

両方のディレクトリを検索パスに載せた状態では、単純な型チェックは毎回まったく同じ形で失敗しました。20回中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であり、Xcode 26.6のclangはすでにこれを出力します。検索パスの片方を外すと同じコンパイルが成功することから、引き金はディスク上に存在することではなく、1回のコンパイルから見えることだと確認できました⁸。

依存関係スキャナの振る舞いは異なります。そしてこの違いこそが、Appleが「場合があります」と書いた理由のすべてです。同じ2つのモジュールマップをswiftc -scan-dependenciesに20回通したところ、結果は3種類に分かれました。SIGSEGVによるクラッシュが9回、abortが5回、正常終了が6回です⁸。クラッシュした実行のスタックトレースはperformParallelClangModuleLookupを通過しており、これはAppleが置き換えたと述べている並列検索での競合と整合します。ただし、この非決定性をその競合に帰するのは、トレースに対する私の読みであってAppleの言明ではありません。

Appleが名指しした2つ目のケースは、静かなほうです。iPhoneOS SDKに実在するモジュールであるSQLite3を宣言するベンダー提供のモジュールマップを書き、検索パスに載せてコンパイルしてみました⁸。

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

コンパイルは成功しました。終了コード0、警告なし、noteなし、いかなる診断も出ません。そこで同じ構成に対してsqlite3_openを求めてみます⁸。

error: cannot find 'sqlite3_open' in scope

ベンダー用ディレクトリを検索パスから外せば、同一のファイルがコンパイルできます。ベンダー提供のモジュールマップはSDKのSQLite3を完全に覆い隠したのに、ツールチェーンは何も言いませんでした。つまり現時点では、ベンダーによる再宣言のケースは派手に失敗するのではなく、インポートしたつもりのモジュールからAPIが消えるという形で失敗します。AppleのノートはXcode 27のスキャンがそこで「エラーを報告する場合があります」と述べており、それが実現すれば、静かな覆い隠しはビルド失敗へと変わります。

私のビルド環境はXcode 26.6（ビルド17F113）なので、ここまでの診断はすべて1つ前のツールチェーンから出たものです⁷⁸。Xcode 27のエラーテキストは報告できませんし、捏造もしていません。診断の仕組みも、grepすべき文字列も、Appleが引退させると述べている寛容さも、すべて今日すでに存在しています。

モジュール名の重複を監査する

宣言されたモジュール名の列挙は1行のgrepで済みそうに見えますが、モジュールマップ言語の2つの構文が誤った答えを生みます。

extern module Foo "Foo.modulemap"は前方参照であって定義ではありません。AppleのSDKは1つのモジュールマップの中でこれを79回使っています⁷。素朴なスキャンは、この参照と本物の定義をFooの2つの宣言として数えてしまいます。2つ目に、module Darwin.C { ... }はドット付きのmodule-idで、別の場所で宣言されたモジュールを拡張するものです。SDKのモジュールマップ13件がmodule Darwin.somethingを開いており、先頭要素をトップレベル宣言として読むと、この13件が本物のDarwin宣言と一緒くたにされ、14ファイルの衝突という誤報になります⁷。この2種類の偽陽性は、どちらも私の最初の草案に現れました。

これらを生き延びたコマンドは、コメント、波括弧の深さ（ネストしたexplicit moduleのサブモジュールを除外するため）、そして空白を含むパスに対応しています。

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

利用できる最強の陰性対照はApple自身のSDKです。ツールチェーンが動作している以上、これはルールを満たしているはずだからです。iPhoneOS 26.5のSDKに向けて実行すると、usr/include配下で1,099件、フレームワークのモジュールマップ全体で205件のトップレベル宣言が見つかり、いずれも重複はゼロでした⁷。衝突するよう作ったフィクスチャに向ければ、重複名と両方のファイルを名指しします⁸。

除外指定は軽くありません。-not -path '*/build/*'は.build/を除外しません。パターンにはディレクトリ名がそのまま必要だからです。しかもSwiftPMは生成したモジュールマップを.buildへ大量に書き込みます。.buildを残したまま実行したことが、7プロジェクトで唯一の「重複」を生みました。6ファイルのGrappleCoreと3ファイルのGrappleRenderで、すべてSwiftPMの出力、2つのSwiftターゲットが異なるビルドルートにまたがったものです⁹。この9件はバイト単位でも一致しておらず、その理由が示唆に富みます。それぞれが同じモジュール名で、自分のビルドルート内にある生成ヘッダへの絶対パスを包んでいるだけなので、1つの文字列だけが違い、意味のある差はどこにもありません。これらを衝突と呼ぶ監査は、本当の問題に到達する前に信用を使い果たします。

Xcodeは同じ偽陽性を、より紛れの無い形で製造します。1つのDerivedDataツリーの中で、各Swiftパッケージの生成モジュールマップを2度、GeneratedModuleMaps-iphonesimulator/とターゲット自身の中間生成物へ書き込みます。しかもヘッダのパスはどちらも相対です。あるプロジェクトのツリーでは15の名前がそれぞれ2回現れ、15組すべてがバイト単位で同一でした⁹。監査の対象はソースに限定し、ビルド成果物は外してください。

7プロジェクトに何があったか

Xcode 26.6上で、7つのXcodeプロジェクトに両方の監査をかけました。正直な結果は、きれいなゼロです⁹。

OTHER_LDFLAGSは7プロジェクトすべてで未設定、.xcconfigファイルはどこにも存在せず、CocoaPodsもCarthageも、ベンダー提供の.frameworkや.xcframeworkもありません⁹。モジュール名の監査では391件のモジュールマップを調べました。プロジェクトディレクトリ内が204件、XcodeのGUIビルドが着地する共有DerivedData内が187件で、そのすべてがビルド成果物です⁹。手書きのモジュールマップを持つリポジトリは1つもありません。

2つのゼロには同じ原因があり、持ち帰る価値があるのはそこです。影響を受けるのは複数言語が混在したプロジェクトであり、これらはそうではないということ。463件のSwiftファイルに対して、Objective-Cはゼロ、C++もゼロ、Cソースもゼロ。Swift以外でコンパイルされるコードは、WaterのMetalシェーダ2件だけです⁹。そもそも危険域に無いコードベースからの陰性結果は、危険そのものについては弱い証拠ですが、誰が監査すべきかについては強い証拠になります。

ゼロよりも重要な事実が2つあります。解決済みパッケージの中で唯一の手書きモジュールマップはswift-cryptoのもので、CCryptoBoringSSL、CCryptoBoringSSLShims、CXKCP、CXKCPShimsという4つのCシムを提供しており、いずれも名前は重複しません⁹。そして、この一群が宣言する名前は、SDKのClangモジュール名前空間のどこにも現れません。iPhoneOS 26.5のSDKでコマンドが見つけたトップレベル名1,318件すべてと照合済みです⁹。Supabase経由で入ってくる汎用的な名前ですら外れています。SDKが宣言するClangモジュールにはFoundation、UIKit、SQLite3はあっても、Crypto、Storage、Authは存在しません。

足元で動くC++のデプロイメント下限

隣接する変更が1つ、-ld_classicを抱えているのと同じC++プロジェクトを直撃します。Appleは下限を引き上げ、macOSだけを名指ししました。「C++標準ライブラリがサポートするmacOSの最小デプロイメントターゲットは11.0に引き上げられました」⁵。

同じ項目は脱出口を用意し、その次の一文で撤去の時期まで示しています。libc++は、狭義弱順序ではない比較子に対するstd::mapとstd::setのlower_boundとupper_boundの結果を変更しました。_LIBCPP_ENABLE_LEGACY_TREE_LOWER_UPPER_BOUNDを定義すれば「これらの操作は従来の実装に戻ります」。続けてこうあります。「この脱出口は今後のリリース（おそらく次のリリース）で削除されます」⁵。関連する変更として、multimap::findとmultiset::findが必ずしも最初の等価要素を返さなくなりました。Appleはこの挙動について「標準では保証されていなかった」がlibc++は常に提供していたと注記しており、こちらにはオプトアウトがありません⁵。このマクロは修正ではなく、移行のためのチケットとして扱ってください。

FAQ

なぜ自分のプロジェクトに-ld_classicが入っているのですか

ほぼ間違いなく、AppleのXcode 15リリースノートがそう処方したからです。そこにある2件のKnown Issueが、OTHER_LDFLAGSへの-Wl,-ld_classic追加を推奨していました。1件は弱定義シンボルを使うバイナリがiOS 14およびmacOS 12以前で実行時にクラッシュする問題で、Appleは「主にC++プロジェクトに影響する」と注記しています。もう1件はLTOオブジェクトファイルが弱シンボルのインポートを非弱としてリンクする問題です³。AppleはXcode 16でこのオプションを非推奨とし、Xcode 27でその背後のリンカを削除しました¹⁴。もしフラグが残っているなら、代替を探す前に、元の不具合が今も再現するかどうかを確かめてください。

プロジェクト内でClangモジュール名の重複を見つけるには

すべてのモジュールマップからトップレベルのモジュール宣言を列挙し、2つのファイルに現れる名前を探し、結果からビルドディレクトリを外します。この作業をgrep以上のものにしている要因は3つです。extern module Foo "path"は定義ではなく参照であること、module Foo.BarはFooを宣言するのではなく別の場所で宣言されたモジュールを拡張すること、そしてネストしたexplicit moduleのサブモジュールはトップレベル名と衝突しないことです⁶。.build、build、DerivedDataは明示的に除外してください。-not -path '*/build/*'は.buildを取りこぼしますし、SwiftPMもXcodeも生成モジュールマップを日常的に重複させるからです⁹。

Xcode 27ではエラーはどう見えるのですか

私には言えませんし、Xcode 26でビルドしている人には誰にも言えません。私のマシンはXcode 26.6（ビルド17F113）で動いているので、Xcode 27の出力は一切報告しません⁷⁸。同じ名前を宣言する2つのモジュールマップに対してXcode 26.6が出すのは、error: redefinition of module 'Widget'とnote: previously defined hereで、単純な型チェックでは毎回そうなります⁸。Xcode 27についてのAppleの表現はスキャンが「エラーを報告する場合があります」なので、誰かが推測した文字列ではなくredefinition of moduleをログから探してください。

モジュール名の一意性違反はデプロイメントターゲットに依存しますか

依存しません。Appleは要件を単一のSwift依存関係スキャンアクションに対して定めており、この項目ではOSバージョンもSDKもデプロイメントターゲットも名指ししていません²。リンカの変更も同じ読み方になり、ツールチェーンからの削除として書かれています¹。どちらもXcode 27での最初のビルドで着地します。同じサイクルにあるSDK起因の要件ではなく、@Stateマクロと同じ側の変更です。

押さえておきたい点

iOS開発者向け: - -ld_classicをgrepするのではなく、xcodebuild -showBuildSettings -configuration Release -sdk iphoneosでOTHER_LDFLAGSを問い合わせてください。解決済み設定に無ければ未設定という意味になりますが、テキスト検索に無くても何の意味もありません⁹。 - ビルドログで探すのはredefinition of moduleです。Xcode 26.6がすでに出している診断であり、捏造したXcode 27のエラーテキストではありません⁸。

ベンダー提供のCまたはC++依存を抱えるチーム向け: - ベンダー提供のmodule.modulemapファイルを、まずSDKの名前空間と突き合わせて監査してください。Appleが名指ししているのがこのケースであり、しかも現在は静かに失敗します。私のベンダー版SQLite3シムは終了コード0でコンパイルが通り、sqlite3_openを消し去りました⁸。 - 監査対象はソースに絞り、.build、build、DerivedDataを除外してください。391件のモジュールマップに現れた見かけ上の重複は、すべて単一のSwiftターゲット向けに生成されたビルド成果物でした⁹。

リリース管理者向け: - どちらの変更もツールチェーン起因として扱い、SDK移行ではなくXcode 27での最初のビルドに合わせて計画してください。デプロイメントターゲットへの言及も、実行時の要素もありません¹²。 - Appleの留保はチケットに書き残しておきましょう。スキャンは「エラーを報告する場合があります」であり、1件の衝突を20回走らせて3種類の結果が出た以上、1度ビルドが通ったことは何の証明にもなりません²⁸。

27系のサイクルは、毎回違う場所で失敗し続けています。起動画面のキーは申請を止め、シーンライフサイクルの義務化は起動を止め、@Stateマクロはソースの段階でビルドを止めます。リンカの削除とモジュール名ルールが止めるのは、そのさらに一段下、誰も意図して設定しないツールチェーンの部分です。シリーズ全体のハブはApple エコシステムシリーズにあります。

参考文献