首先聲明
因?yàn)槲沂窃谡鏅C(jī)上編譯的項(xiàng)目，所以報(bào)錯(cuò)的架構(gòu)（CPU指令集）為arm64。
- 如果我們使用64位模擬器（iPhone simulators 5s 或更高版本）編譯或者運(yùn)行項(xiàng)目，就會(huì)報(bào)以下錯(cuò)誤：
- Undefined symbols for architecture x86_64:
- 如果我們使用32位模擬器（iPhone simulators 5 或更低版本）編譯或者運(yùn)行項(xiàng)目，就會(huì)報(bào)以下錯(cuò)誤：
- Undefined symbols for architecture i386:
Undefined symbols for architecture XXX:類似的錯(cuò)誤是一個(gè)開發(fā)中經(jīng)常遇到的問(wèn)題，凡是涉及到第三方靜態(tài)庫(kù)的項(xiàng)目，都不可避免的遇到過(guò)這一類錯(cuò)誤。為了說(shuō)明錯(cuò)誤的原因和加深對(duì)解決方案的理解。筆者采用了故意復(fù)現(xiàn)問(wèn)題的方式來(lái)驗(yàn)證問(wèn)題的解決方案：
即：故意給工程進(jìn)行錯(cuò)誤的配置或者刪除某些配置，使工程編譯不通過(guò)，然后記下編譯器報(bào)的錯(cuò)誤，驗(yàn)證什么情況下會(huì)報(bào)這種錯(cuò)。
首先聲明，我的工程中引用（并非通過(guò)cocoapods引用）了友盟的統(tǒng)計(jì)SDK，名稱叫做libMobClickLibrary.a。存儲(chǔ)在工程的third_party目錄下，如下圖：
原因之一：沒(méi)有鏈接lib庫(kù)而報(bào)錯(cuò)
lib是library的意思，lib庫(kù)就是指后綴名為.a的靜態(tài)庫(kù)。
(1) 刪除General -> Linked Frameworks and Libraries 下的libMobClickLibrary.a。如下圖分別是刪除前和刪除后的對(duì)比：
刪除前：
刪除后：
(2) 再次真機(jī)編譯項(xiàng)目，我們就能如愿以償?shù)目吹絻蓚€(gè)經(jīng)典的的錯(cuò)誤 "OBJC_CLASS$_MobClick", referenced from: 和 linker command failed with exit code 1 (use -v to see invocation)，點(diǎn)擊第一個(gè)錯(cuò)誤，如下圖：
（3）然后看到 Undefined symbols for architecture arm64：
但是我們?cè)趺粗朗菦](méi)有鏈接libMobClickLibrary.a庫(kù)而不是其他的什么庫(kù)呢？這還要取決于這句"_OBJC_CLASS_$_MobClick", referenced from:。其中_OBJC_CLASS_$_MobClick中的MobClick就是我們引用的libMobClickLibrary.a中的一個(gè)文件。因?yàn)槲艺娴氖窃?code>AliyunSalesCustomerListTableViewManager.m中通過(guò)#import "MobClick.h"引用了MobClick.h，如下圖：
當(dāng)然，如果我們引用了libMobClickLibrary.a庫(kù)中的其他文件，那么OBJC_CLASS$_后面就不是MobClick了，這個(gè)大家應(yīng)該是很好理解的。
有的時(shí)候，因?yàn)楹竺娴念惷谌降膸?kù)名沒(méi)有任何相似處，比如庫(kù)名叫做libAAA.a，而報(bào)錯(cuò)的類名卻是BBB。此時(shí)，我們通過(guò)后面的類名根本不能準(zhǔn)確的判斷出這個(gè)BBB屬于哪個(gè)庫(kù)，也就不知道該鏈接哪個(gè)庫(kù)。這種情況下，我們可以通過(guò)referenced from:提示后面的文件名來(lái)判斷BBB到底屬于哪個(gè)靜態(tài)庫(kù)，因?yàn)槲覀冏约旱哪硞€(gè)類文件不太可能import很多第三方的庫(kù)，這種情況下，采取這種方式比較好判斷。
總結(jié)：綜上，我們可知：項(xiàng)目中如果用到了某個(gè)第三方靜態(tài)庫(kù)，但lib靜態(tài)庫(kù)或者framework靜態(tài)庫(kù)沒(méi)有被鏈接時(shí)，就會(huì)遇到Undefined symbols for architecture XXX這一類的錯(cuò)誤。
** 原因：**編譯項(xiàng)目時(shí)，因?yàn)殪o態(tài)庫(kù)沒(méi)有鏈接進(jìn)工程，所以靜態(tài)庫(kù)就不會(huì)參與編譯，而項(xiàng)目某些文件（.m文件）又引用（或者說(shuō)依賴）了靜態(tài)庫(kù)，所以自然會(huì)報(bào)錯(cuò)，而報(bào)的錯(cuò)就是經(jīng)典的 Undefined symbols for architecture XXX這一類的錯(cuò)誤。
解決方案：下次遇到這類問(wèn)題，我們只需要在Linked Frameworks and Libraries 中添加指定的靜態(tài)庫(kù)即可！
還原項(xiàng)目
因?yàn)閯偛艅h除了libMobClickLibrary.a文件，我們要想讓項(xiàng)目可以恢復(fù)到完美編譯運(yùn)行的狀態(tài)，需要在Linked Frameworks and Libraries 添加libMobClickLibrary.a庫(kù)，如下圖：
因?yàn)槭堑谌綆?kù)，不是系統(tǒng)提供的庫(kù)，所以需要到我們自己的目錄中添加：如下圖展示了添加步驟：
至此，缺失的靜態(tài)庫(kù)已經(jīng)被鏈接進(jìn)工程中，再次編譯項(xiàng)目就不會(huì)報(bào)這個(gè)錯(cuò)誤。當(dāng)然，如果還報(bào)類似錯(cuò)誤，說(shuō)明你的項(xiàng)目中還需要鏈接其他的靜態(tài)庫(kù)，鏈接方法相同。
原因之二：沒(méi)有鏈接.framework靜態(tài)庫(kù)而報(bào)錯(cuò)
上面說(shuō)明了工程中因?yàn)槿鄙冁溄觢ib庫(kù)導(dǎo)致報(bào)錯(cuò)的一種情況。iOS開發(fā)中有兩種格式的靜態(tài)庫(kù)（.a格式和.framework格式）。所以，我們也不難猜測(cè)：缺少鏈接.framework格式的靜態(tài)庫(kù)也會(huì)導(dǎo)致同樣的錯(cuò)誤。
如果我們引用的第三方庫(kù)并不是.a格式的靜態(tài)庫(kù)，而是.framework格式的靜態(tài)庫(kù)，在Linked Frameworks and Libraries中沒(méi)有被鏈接的情況下，也會(huì)報(bào)同樣的錯(cuò)誤。比如我在Linked Frameworks and Libraries 中刪除 PushCenterSDK.framework靜態(tài)庫(kù)(這個(gè)靜態(tài)庫(kù)存在于木紋中，不是cocoapods管理的)，如下圖:
（1）在Linked Frameworks and Libraries中刪除PushCenterSDK.framework
(2)模擬器編譯項(xiàng)目，出現(xiàn)以下三個(gè)錯(cuò)誤：
（3）點(diǎn)擊第一個(gè)錯(cuò)誤，查看錯(cuò)誤詳情，如下圖：
發(fā)現(xiàn)：如果缺少鏈接.framework格式的靜態(tài)庫(kù)，也會(huì)報(bào)相同的錯(cuò)誤，所以，不管我們?nèi)鄙冁溄拥氖?a靜態(tài)庫(kù)還是.framework靜態(tài)庫(kù)，只要在Link Frameworks and Libraries 中沒(méi)有正確鏈接進(jìn)去，都會(huì)報(bào)相同的錯(cuò)誤，即：Undefined symbols for architecture XXX:。
值得注意的是，此處報(bào)了三個(gè)錯(cuò)誤，原因在于，YunFuPushCenter.m文件中引用了PushCenterSDK.framework的兩個(gè)文件(如下圖)，所以會(huì)多報(bào)一個(gè)錯(cuò)誤，這個(gè)是比較好理解的：
原因之三：extern引用不存在的全局變量而報(bào)錯(cuò)
開發(fā)中，我們很有可能用到全局變量，比如在delegate.m文件中定義了一個(gè)int 型全局變量globalVar，在ViewController.m文件中通過(guò)extern int globalVar; 而引用A.m文件的這個(gè)全局變量。這樣是沒(méi)問(wèn)題。但是如果我們不小心把extern int globalVar 寫成 extern int globalVariate，且在ViewController.m文件中使用了這個(gè)globalVariate變量（代碼如下）。
#import "AppDelegate.h"
@interface AppDelegate ()
@end
@implementation AppDelegate
int globalVar; // 生命一個(gè)全局變量
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
return YES;
}
#import "ViewController.h"
@interface ViewController ()
@end
@implementation ViewController
extern int globalVariate; // 引用一個(gè)不存在的全局變量
- (void)viewDidLoad {
[super viewDidLoad];
globalVariate = 10; // 給不存在的全局變量賦值
}
@end
編譯上面代碼也會(huì)報(bào)同樣的錯(cuò)誤，如下圖：
點(diǎn)擊錯(cuò)誤查看詳情，如下圖：
原因：因?yàn)閑xtern int globalVariate并沒(méi)有定義名為globalVariate的變量，而是引用了一個(gè)名字叫做globalVariate的全局變量。當(dāng)我們使用globalVariate時(shí)候，系統(tǒng)發(fā)現(xiàn)這個(gè)變量根本沒(méi)有定義，就會(huì)報(bào)這個(gè)錯(cuò)誤。
原因之四：Compile Sources中沒(méi)有添加對(duì)應(yīng)的.m文件而報(bào)錯(cuò)
有時(shí)候，我們項(xiàng)目中并沒(méi)有以靜態(tài)庫(kù)的形式引用第三方庫(kù)，而是直接使用的三方源碼。也有可能出現(xiàn)相同的錯(cuò)誤。如下圖：
項(xiàng)目中以源碼的形式引用了react native。某一次執(zhí)行了git pull命令后，再編譯項(xiàng)目，就出現(xiàn)了下面這個(gè)錯(cuò)誤。其意為：RCTSegmentedControlManager.m文件引用了RCTSegmentedControl文件，但是找不到RCTSegmentedControl.m這個(gè)文件（.h文件是不參與編譯的）。同理，RCTScrollView.m文件和RCTRefreshControlManager.m文件中引用了RCTRefreshControl.m文件，但是也找不到RCTRefreshControl.m文件。
于是乎，我們?nèi)uild Phases -> Compile Sources中搜索RCTRefreshControl或者RCTSegmentedControl，確實(shí)沒(méi)有找到對(duì)應(yīng)的.m文件。如下圖1和圖2：
于是，把這兩個(gè).m文件加進(jìn)去，如下圖1和圖2：
最終，再次command + R，編譯通過(guò)！
綜上，如果某個(gè).m文件沒(méi)有被添加在Compile Sources中，那么這個(gè).m文件就不會(huì)參與編譯，導(dǎo)致其他文件引用該文件時(shí)，就會(huì)報(bào)錯(cuò): Undefined symbols for architecture XXX: 解決辦法，就是把這個(gè).m文件添加到Compile Sources中。
文／VV木公子（簡(jiǎn)書作者）
PS:如非特別說(shuō)明，所有文章均為原創(chuàng)作品，著作權(quán)歸作者所有，轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，并注明出處，所有打賞均歸本人所有！
如果您是iOS開發(fā)者，或者對(duì)本篇文章感興趣，請(qǐng)關(guān)注本人，后續(xù)會(huì)更新更多相關(guān)文章！敬請(qǐng)期待！
