庫(kù)動(dòng)態(tài)庫(kù)實(shí)戰(zhàn))
編譯報(bào)錯(cuò)里我最熟悉的一句就是undefined reference to std::cout。說它熟悉是因?yàn)閹缀趺總€(gè) C/C 初學(xué)者都會(huì)被它攔住一次更離譜的是很多人查了半天代碼發(fā)現(xiàn)自己寫得一點(diǎn)問題都沒有。后來才明白問題壓根不在代碼而在編譯和鏈接這兩個(gè)階段上。所以我想把 C/C 編譯鏈接這一整套鏈路以及基本庫(kù)這個(gè)概念徹底拆開講明白編譯到底分幾步、鏈接器在做什么、靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)怎么選、環(huán)境怎么搭、報(bào)錯(cuò)怎么查。內(nèi)容不做太多理論糾纏全部是實(shí)操里沉淀下來的經(jīng)驗(yàn)適合剛?cè)腴T C/C以及正在跟各種鏈接錯(cuò)誤較勁的同學(xué)。1. 從源碼到目標(biāo)文件編譯過程的四道工序與報(bào)錯(cuò)定位1.1 四道工序各自在干什么很多人在終端里敲一句gcc hello.c -o hello管這叫編譯。這句話確實(shí)能幫你生成可執(zhí)行文件但它背后發(fā)生的事情遠(yuǎn)比一條命令復(fù)雜。加上-v參數(shù)運(yùn)行一遍你能看到驅(qū)動(dòng)程序依次調(diào)用了cc1真正的編譯器、as匯編器、collect2和ld鏈接器。也就是說這條命令最少拆成四個(gè)階段才完整。第一階段是預(yù)處理。運(yùn)行g(shù)cc -E hello.c -o hello.i做的是頭文件展開、宏替換、條件編譯分支選擇。你寫了一句#include stdio.h預(yù)處理階段會(huì)把stdio.h的完整內(nèi)容原樣粘貼到源文件里。一個(gè)普通的 hello 程序預(yù)處理之后文件體積能瞬間膨脹到幾千行。如果你看到的報(bào)錯(cuò)是某個(gè)頭文件找不到多半就在這一步翻車。第二階段是編譯。gcc -S hello.i -o hello.s把預(yù)處理后的代碼翻譯成匯編語言同時(shí)做嚴(yán)格的語法和類型檢查。項(xiàng)目里最耗時(shí)的優(yōu)化動(dòng)作-O2、-O3也發(fā)生在這一步幾十萬行的工程編譯半天大頭全在這里。編譯報(bào)錯(cuò)的表現(xiàn)是報(bào)錯(cuò)信息里帶有具體的源碼行號(hào)還會(huì)用^指向出問題的位置這類錯(cuò)誤是語法或類型層面的直接改代碼就行。第三階段是匯編。gcc -c hello.s -o hello.o把匯編代碼翻譯成機(jī)器指令生成目標(biāo)文件。Linux 下這個(gè)文件是 ELF 格式Windows 下是 COFF 格式。但此時(shí)的hello.o到處都是坑它引用了printf、memcpy這類外部符號(hào)卻還不知道這些符號(hào)在最終程序里的內(nèi)存地址。第四階段是鏈接。把多個(gè).o文件、庫(kù)文件拼裝成最終可執(zhí)行文件完成符號(hào)解析和地址重定位。gcc hello.o -o hello跑的就是這一步。絕大多數(shù)讓新手頭皮發(fā)麻的報(bào)錯(cuò)比如undefined reference、multiple definition都是在這一階段丟出來的。1.2 按報(bào)錯(cuò)信息快速判斷問題出在第幾步這四步對(duì)應(yīng)的報(bào)錯(cuò)形態(tài)差別非常大學(xué)會(huì)一眼判斷能省下大量無用的排查。預(yù)處理錯(cuò)誤通常是fatal error: xxx.h: No such file or directory解決方案是檢查-I參數(shù)和頭文件路徑。編譯錯(cuò)誤報(bào)錯(cuò)帶源碼行號(hào)內(nèi)容多為syntax error、類型不匹配、變量未聲明直接改代碼。匯編錯(cuò)誤日常業(yè)務(wù)代碼中很少見基本出現(xiàn)在內(nèi)聯(lián)匯編寫法不對(duì)或者目標(biāo)平臺(tái)不支持的指令集上。鏈接錯(cuò)誤報(bào)錯(cuò)帶符號(hào)名但不帶源碼行號(hào)比如undefined reference to bar、cannot find -lfoo、multiple definition of bar?？吹竭@類報(bào)錯(cuò)請(qǐng)先停止檢查語法轉(zhuǎn)去檢查你有沒有把正確的庫(kù)喂給鏈接器。提示編譯錯(cuò)誤是你話沒說對(duì)鏈接錯(cuò)誤是你需要的工具沒帶齊。記住這句話報(bào)錯(cuò)定位會(huì)快很多。鏈接階段要去找?guī)爝@也是基本庫(kù)這個(gè)概念登場(chǎng)的時(shí)機(jī)。庫(kù)分運(yùn)行時(shí)庫(kù)、靜態(tài)庫(kù)、動(dòng)態(tài)庫(kù)每一種在鏈接鏈路里的作用都不一樣。2. 基本庫(kù)到底是個(gè)什么東西運(yùn)行時(shí)庫(kù)、靜態(tài)庫(kù)與動(dòng)態(tài)庫(kù)的分工2.1 運(yùn)行時(shí)庫(kù)程序出生前就必須存在的底座基本庫(kù)在不同語境下指的東西不一樣但最核心的永遠(yuǎn)是運(yùn)行時(shí)庫(kù)。C 語言有 libcLinux 上通常是 glibc資源受限的嵌入式環(huán)境里常見 muslC 有 libstdcGCC 配套和 libcClang 配套Windows 上還有 UCRT、MSVC CRT 這類東西。只要你寫 C/C這些庫(kù)就是繞不開的底座。printf、malloc、new、delete、std::vector、std::cout的實(shí)現(xiàn)全部封裝在里面。這里有一個(gè)初學(xué)者必踩的經(jīng)典坑gcc和g的區(qū)別。用gcc去編譯一個(gè).cpp文件編譯階段沒問題到鏈接階段就會(huì)報(bào)undefined reference to std::cout一類錯(cuò)誤原因是gcc這個(gè)驅(qū)動(dòng)在鏈接時(shí)默認(rèn)不帶 C 運(yùn)行時(shí)庫(kù)。正確做法是編譯 C 用g。g本質(zhì)上也是調(diào)用同一個(gè)編譯器只是會(huì)在鏈接命令里自動(dòng)追加-lstdc。你不信的話給編譯命令加上-v看看它傳給鏈接器的參數(shù)就明白了。2.2 靜態(tài)庫(kù)與動(dòng)態(tài)庫(kù)兩種封裝形態(tài)的取舍庫(kù)本身又以兩種形態(tài)存在。靜態(tài)庫(kù)在 Linux 下是.a文件Windows 下是.lib。它本質(zhì)上是多個(gè)目標(biāo)文件打包在一起的壓縮包用ar rcs libcalc.a add.o sub.o就能生成。鏈接器在處理靜態(tài)庫(kù)時(shí)會(huì)把用到的目標(biāo)文件完整復(fù)制進(jìn)可執(zhí)行文件所以最終程序不需要依賴外部庫(kù)文件。動(dòng)態(tài)庫(kù)在 Linux 下是.soWindows 下是.dllmacOS 下是.dylib。鏈接階段只會(huì)檢查符號(hào)是否存在并記錄依賴關(guān)系和符號(hào)偏移真正的代碼加載發(fā)生在程序運(yùn)行時(shí)。好處是多個(gè)程序可以共享同一份庫(kù)文件更新庫(kù)只需要替換文件壞處是會(huì)出現(xiàn)所謂依賴地獄——換一臺(tái)機(jī)器可執(zhí)行文件就可能因?yàn)檎也坏侥硞€(gè).so而直接拒絕啟動(dòng)。對(duì)比項(xiàng)靜態(tài)庫(kù)動(dòng)態(tài)庫(kù)常見后綴.a/.lib.so/.dll/.dylib鏈接期行為目標(biāo)文件復(fù)制進(jìn)程序只登記符號(hào)依賴運(yùn)行期依賴無依賴庫(kù)文件存在且版本匹配可執(zhí)行文件體積偏大偏小更新庫(kù)需要重新編譯程序替換庫(kù)文件即可部署復(fù)雜度低高選擇的標(biāo)準(zhǔn)其實(shí)很樸素追求獨(dú)立部署、環(huán)境不可控優(yōu)先靜態(tài)鏈接追求體積小、更新靈活選動(dòng)態(tài)庫(kù)。另外-static參數(shù)可以強(qiáng)制全程靜態(tài)鏈接。我在排查動(dòng)態(tài)庫(kù)沖突問題時(shí)經(jīng)常臨時(shí)編一個(gè)靜態(tài)版本做對(duì)照組如果靜態(tài)版一切正?；究梢詳喽▎栴}出在動(dòng)態(tài)庫(kù)加載的環(huán)節(jié)。2.3 親手做出并鏈接一個(gè)基本庫(kù)命令行里創(chuàng)建庫(kù)并不神秘。假設(shè)你寫了一個(gè)計(jì)算器提供add和sub兩個(gè)函數(shù)# 編譯生成目標(biāo)文件 gcc -c add.c sub.c # 創(chuàng)建靜態(tài)庫(kù) libcalc.a ar rcs libcalc.a add.o sub.o # 編譯主程序并鏈接靜態(tài)庫(kù) gcc main.c -L. -lcalc -o main-L.告訴鏈接器在當(dāng)前目錄搜索庫(kù)文件-lcalc告訴它找一個(gè)叫l(wèi)ibcalc.a或libcalc.so的文件。注意 Linux 庫(kù)的命名規(guī)則文件必須叫l(wèi)ib加庫(kù)名再加后綴寫-l時(shí)既不帶lib前綴也不帶后綴。如果你把庫(kù)文件名起成calc.a而不是libcalc.a就算路徑對(duì)了鏈接器照樣找不到。動(dòng)態(tài)庫(kù)的命令稍稍多一點(diǎn)gcc -c -fPIC add.c sub.c gcc -shared -fPIC -o libcalc.so add.o sub.o gcc main.c -L. -lcalc -o main-fPIC表示生成位置無關(guān)代碼這是動(dòng)態(tài)庫(kù)的硬性要求。原因在于動(dòng)態(tài)庫(kù)在運(yùn)行時(shí)被映射到進(jìn)程地址空間的哪個(gè)位置不確定代碼內(nèi)部的跳轉(zhuǎn)和引用不能寫死絕對(duì)地址。3. 鏈接器的工作細(xì)節(jié)符號(hào)解析、庫(kù)順序與搜索路徑3.1 符號(hào)表、重定位與目標(biāo)文件里的坑鏈接器干的事情概括起來就兩件符號(hào)解析和重定位。符號(hào)解析是把代碼里所有對(duì)外部符號(hào)的引用和某個(gè)目標(biāo)文件或庫(kù)里的定義對(duì)上。每個(gè)目標(biāo)文件都有一張符號(hào)表用nm main.o就能看到。輸出里的T表示已經(jīng)定義的全局代碼符號(hào)U表示未定義、等著鏈接器去外面找的符號(hào)。我用這個(gè)命令排查過大量 undefined reference 問題把一個(gè)符號(hào)在它聲稱依賴的庫(kù)文件里跑一遍nm如果顯示為T說明它確實(shí)定義在這里如果到處都找不到那要么庫(kù)沒鏈接要么鏈接順序不對(duì)要么符號(hào)被 C 名字修飾過了。重定位則是在把所有目標(biāo)文件合并到一起后把代碼里那些懸空的符號(hào)引用替換成最終運(yùn)行時(shí)確定的虛擬內(nèi)存地址。這也是為什么一個(gè)簡(jiǎn)單的程序也要經(jīng)過鏈接才能跑起來——目標(biāo)文件里的代碼地址都是空的程序無法直接被操作系統(tǒng)加載。3.2 庫(kù)鏈接順序?yàn)槭裁词?GNU 工具鏈的經(jīng)典坑GNU ld 在處理靜態(tài)庫(kù)時(shí)有一個(gè)小脾氣它只會(huì)提取能夠解決當(dāng)前未定義符號(hào)的目標(biāo)文件而且默認(rèn)從左到右只掃描一遍。這就導(dǎo)致庫(kù)的書寫順序會(huì)直接影響鏈接成敗。假設(shè)libbar.a引用了libfoo.a里的符號(hào)鏈接命令必須寫成gcc main.o -lbar -lfoo -o app如果你顛倒次序?qū)懗?lfoo -lbar鏈接器掃描libfoo.a時(shí)發(fā)現(xiàn)沒有任何人引用它的符號(hào)直接跳過掃到libbar.a時(shí)才發(fā)現(xiàn)需要libfoo.a里的東西可這時(shí)libfoo.a已經(jīng)被處理完了于是報(bào)出 undefined reference。解決的辦法有兩個(gè)一是把依賴別人的庫(kù)寫在前面二是用--start-group和--end-group把多個(gè)庫(kù)包起來讓鏈接器反復(fù)掃描直到?jīng)]有新符號(hào)被解析出來gcc main.o -Wl,--start-group -lbar -lfoo -Wl,--end-group -o app我在真實(shí)項(xiàng)目里見過有人為了這種順序問題折騰一整天最后發(fā)現(xiàn)只是兩個(gè)-l參數(shù)調(diào)換一下順序。如果你用 CMake 管理項(xiàng)目這類問題會(huì)被工具鏈自動(dòng)處理掉這也是我推薦 CMake 的原因之一。3.3 -I、-L、-l 與運(yùn)行時(shí)搜索路徑的職責(zé)邊界-I是頭文件搜索路徑編譯時(shí)用-L是庫(kù)文件搜索路徑鏈接時(shí)用-l指定庫(kù)名也是鏈接時(shí)用。三者各管一段經(jīng)常有人混為一談。頭文件找不到時(shí)查-I庫(kù)文件找不到時(shí)查-L和文件名前綴規(guī)則符號(hào)未定義時(shí)查-l是否遺漏。比鏈接期搜索路徑更隱蔽的是運(yùn)行期搜索路徑。開發(fā)機(jī)上編譯通過、運(yùn)行得好好的程序拷到另一臺(tái)機(jī)器上彈出一句error while loading shared libraries: libcalc.so.1: cannot open shared object file。原因很簡(jiǎn)單動(dòng)態(tài)鏈接器ld.so只會(huì)在系統(tǒng)默認(rèn)目錄和它配置過的目錄里找?guī)旄静粫?huì)看你的當(dāng)前目錄。Linux 下的解決思路有三條設(shè)置環(huán)境變量LD_LIBRARY_PATH/path/to/libs后運(yùn)行臨時(shí)生效適合調(diào)試。把庫(kù)路徑寫入/etc/ld.so.conf.d/下的配置文件然后執(zhí)行l(wèi)dconfig全局生效。在編譯階段就把路徑寫進(jìn)可執(zhí)行文件叫 rpathgcc main.c -L. -lcalc -Wl,-rpath,$ORIGIN -o main。$ORIGIN表示可執(zhí)行文件所在目錄這個(gè)方案對(duì)發(fā)布軟件最友好。如果放在 Makefile 里記得寫成$$ORIGIN不然$ORIGIN會(huì)被 Make 當(dāng)成變量展開。用ldd ./main可以查看可執(zhí)行文件依賴了哪些動(dòng)態(tài)庫(kù)哪些找到了、哪些顯示為not found一眼便知。這是排查運(yùn)行時(shí)缺庫(kù)的第一命令沒有之一。4. 環(huán)境搭建實(shí)操命令行、VSCode 與 CMake 的完整鏈路4.1 編譯器選型GCC、Clang、MSVC 還是 MinGW-w64不同平臺(tái)、不同用途最順手的編譯器不一樣先看一張對(duì)比表編譯器常見平臺(tái)默認(rèn) C 運(yùn)行庫(kù)適用場(chǎng)景GCC / GLinux、嵌入式libstdc最通用近場(chǎng)部署首選Clang / ClangmacOS、Linuxlibc 或 libstdc報(bào)錯(cuò)提示友好現(xiàn)代特性跟進(jìn)快MSVCWindowsUCRT / MSVC CRTWindows 原生開發(fā)、大量 Windows SDKMinGW-w64Windowslibstdc 或 libc想在 Windows 上沿用 GCC 命令習(xí)慣一個(gè)非常重要的提醒MSVC 和 MinGW-w64 的庫(kù)不要混著用。兩者生成的庫(kù)雖然都是 Windows 上的二進(jìn)制格式但各自綁定不同的運(yùn)行時(shí)庫(kù)混用時(shí)能冒出各種匪夷所思的鏈接錯(cuò)誤。選定一條路就走到黑Windows 上用 Visual Studio 的同學(xué)堅(jiān)持 MSVC 工具鏈用命令行習(xí)慣的同學(xué)就堅(jiān)持 MinGW-w64。這兩個(gè)也不要同時(shí)在命令行環(huán)境里搶 PATH很亂。4.2 命令行下最快跑通一套開發(fā)環(huán)境以 Linux 或 macOS 為例最快的驗(yàn)證方式cat hello.cpp EOF #include iostream int main() { std::cout hello, world std::endl; return 0; } EOF g hello.cpp -o hello ./hellomacOS 上有個(gè)額外的坑系統(tǒng)自帶的g其實(shí)是指向 Clang 的符號(hào)鏈接也就是clang。很多時(shí)候這并不影響使用但如果你在 GitHub 項(xiàng)目要求必須用 GCC 真身得先確認(rèn)一下。Windows 上裝好 MinGW-w64 之后最常見的問題是在終端敲g提示不是內(nèi)部或外部命令。這不是編譯器沒裝上而是你沒把安裝目錄下的bin文件夾加進(jìn)系統(tǒng)的 PATH 環(huán)境變量。加上之后重啟終端就好。4.3 VSCode 配置 C/C 環(huán)境三個(gè)配置文件各管什么VSCode 本身不編譯、不運(yùn)行、不調(diào)試 C/C它只是一個(gè)編輯器前端。你先去擴(kuò)展市場(chǎng)裝一個(gè) C/C 擴(kuò)展ms-vscode.cpptools沒有它后面提到的cppdbg調(diào)試類型根本不會(huì)被識(shí)別。所謂配置 C/C 環(huán)境實(shí)際上是配好三個(gè)配置文件。第一個(gè)是tasks.json定義構(gòu)建任務(wù)。按下CtrlShiftB時(shí)會(huì)執(zhí)行{ version: 2.0.0, tasks: [ { label: build hello, type: shell, command: g, args: [-g, hello.cpp, -o, hello], group: {kind: build, isDefault: true} } ] }第二個(gè)是launch.json定義調(diào)試會(huì)話。按下F5時(shí)它會(huì)啟動(dòng)調(diào)試器{ version: 0.2.0, configurations: [ { name: debug hello, type: cppdbg, request: launch, program: ${workspaceFolder}/hello, args: [], cwd: ${workspaceFolder}, MIMode: gdb } ] }macOS 上默認(rèn)調(diào)試器是 lldbMIMode要寫成lldb否則會(huì)報(bào)找不到調(diào)試器。這是不少 mac 用戶在 VSCode 里按 F5 沒反應(yīng)的原因。第三個(gè)是c_cpp_properties.json它負(fù)責(zé)的是編輯器的 IntelliSense代碼補(bǔ)全、跳轉(zhuǎn)定義、紅波浪線。它只影響編輯體驗(yàn)不影響實(shí)際編譯。很多同學(xué)把 includePath 改來改去以為編譯行為會(huì)變化其實(shí)編譯只受tasks.json里寫的那條命令控制。includePath 建議直接指到編譯器自帶的頭文件目錄Linux 上是/usr/includeMinGW 的安裝目錄下也有對(duì)應(yīng)的include文件夾。4.4 用 CMake 告別手寫鏈接命令一旦項(xiàng)目里出現(xiàn)了多個(gè)源文件、多個(gè)庫(kù)再靠手寫g參數(shù)就有點(diǎn)吃力了CMake 是更穩(wěn)的選擇。一個(gè)最小可用的CMakeLists.txtcmake_minimum_required(VERSION 3.16) project(calc_app) add_executable(app main.cpp) add_library(calc add.cpp sub.cpp) target_include_directories(calc PUBLIC .) target_link_libraries(app PRIVATE calc)target_link_libraries會(huì)按依賴關(guān)系自動(dòng)處理鏈接順序這是它對(duì)我最大的價(jià)值——再也不用手工排列-l的先后次序。使用 CMake 時(shí)有一個(gè)非常容易出現(xiàn)、又非常好解決的坑改了CMakeLists.txt之后舊有的構(gòu)建緩存不會(huì)自動(dòng)全部失效有時(shí)行為會(huì)變得詭異。最干凈的處置就是刪掉 build 目錄重新配置一次。新加了源文件、換了庫(kù)依賴之后感覺哪都不對(duì)先別查代碼刪 build 重來很多情況下問題直接消失。5. 常見鏈接錯(cuò)誤實(shí)戰(zhàn)排查從一條報(bào)錯(cuò)挖到根因5.1 高頻鏈接錯(cuò)誤速查表報(bào)錯(cuò)信息根因排查方向undefined reference to xxx符號(hào)未定義庫(kù)是否漏鏈、順序是否顛倒、函數(shù)名是否拼錯(cuò)、C/C 混編未加 extern Ccannot find -lxxx庫(kù)文件找不到-L路徑是否正確、文件名是否帶lib前綴、庫(kù)是 32 位還是 64 位multiple definition of xxx符號(hào)重復(fù)定義頭文件里是否寫了全局變量定義、多個(gè)庫(kù)是否都定義了同名符號(hào)error while loading shared libraries運(yùn)行時(shí)找不到動(dòng)態(tài)庫(kù)用ldd查看依賴設(shè)置LD_LIBRARY_PATH或 rpathrelocation ... can not be used when making a shared object編譯選項(xiàng)不一致生成動(dòng)態(tài)庫(kù)時(shí)是否全程加了-fPICundefined reference to __gxx_personality_v0用 gcc 鏈接了 C 代碼改用g或顯式添加-lstdc這張表不能覆蓋所有情況但能覆蓋我遇到過的 90%。5.2 兩個(gè)真實(shí)案例第三方庫(kù)順序與 C/C 混編第一個(gè)案例來自一次第三方 SDK 接入。程序引入了libsdk.a編譯階段一切順利鏈接時(shí)冒出一串 undefined reference仔細(xì)看報(bào)錯(cuò)符號(hào)都指向 OpenSSL 的函數(shù)。當(dāng)時(shí)的直覺是-lssl -lcrypto沒加加上之后照樣報(bào)錯(cuò)。后來用nm libsdk.a | grep SSL確認(rèn)符號(hào)確實(shí)沒定義又檢查了系統(tǒng)里libssl.so也真實(shí)存在。最終定位到問題-lssl -lcrypto寫在了libsdk.a前面鏈接器掃描 OpenSSL 庫(kù)時(shí)尚未發(fā)現(xiàn)任何未定義符號(hào)直接跳過去了。修復(fù)就是把這兩個(gè)參數(shù)移動(dòng)到 SDK 庫(kù)之后或者直接用 CMake 聲明依賴關(guān)系。第二個(gè)案例是 C 和 C 混編。同事在 C 項(xiàng)目里調(diào)用一個(gè) C 靜態(tài)庫(kù)函數(shù)名、路徑、庫(kù)文件全都對(duì)得上但鏈接器總報(bào)undefined reference to my_c_function。用nm查庫(kù)文件發(fā)現(xiàn)函數(shù)在庫(kù)里明明存在再看末尾C 那邊引用的符號(hào)已經(jīng)被名字修飾成了_Z14my_c_functionv兩個(gè)名字根本對(duì)不上。原因在于 C 編譯器會(huì)把函數(shù)名按照一定的規(guī)則攪碎變成帶類型信息的長(zhǎng)符號(hào)而 C 編譯器不會(huì)。修復(fù)方法是在 C 側(cè)把 C 的頭文件用extern C包起來extern C { #include c_api.h }這兩個(gè)案例說明同一個(gè)道理鏈接錯(cuò)誤往往不是代碼邏輯不對(duì)而是符號(hào)對(duì)不上。5.3 排查鏈接問題必備的命令行工具nm查看目標(biāo)文件和庫(kù)的符號(hào)表判斷符號(hào)定義在哪、有沒有被名字修飾。ldd查看可執(zhí)行文件的動(dòng)態(tài)庫(kù)依賴找出運(yùn)行時(shí)缺了誰。readelf -d查看 ELF 文件的動(dòng)態(tài)段信息搜索路徑、依賴庫(kù)版本都能看到。objdump -t以更底層的視角查看符號(hào)。LD_DEBUGlibs ./main讓動(dòng)態(tài)鏈接器打印加載過程能看清它按什么順序搜索了哪些目錄這個(gè)調(diào)試手段在定位運(yùn)行時(shí)加載問題時(shí)極其好用。strace -e openat ./main在 Linux 上跟蹤文件打開調(diào)用看看程序到底去哪些路徑找過庫(kù)文件。把這幾條命令組合起來用鏈接類的報(bào)錯(cuò)基本都能快速定位。我個(gè)人的習(xí)慣是遇到鏈接錯(cuò)誤第一件事永遠(yuǎn)不是改代碼而是打開終端跑一條nm和一條ldd先搞清楚問題到底是符號(hào)不存在還是定義沒有被找到。這兩個(gè)方向?qū)?yīng)的解法截然不同想清楚再動(dòng)手能節(jié)省大量瞎試的時(shí)間。另外如果你的項(xiàng)目將來要在多個(gè)平臺(tái)之間搬動(dòng)建議早點(diǎn)從手寫gcc參數(shù)切到 CMake短期看多寫了幾行文件長(zhǎng)期看省掉的是無數(shù)個(gè)人為排庫(kù)順序的深夜。 C/C++編譯鏈接全流程解析：從undefined reference到靜態(tài)庫(kù)動(dòng)態(tài)庫(kù)實(shí)戰(zhàn)
編譯報(bào)錯(cuò)里我最熟悉的一句就是undefined reference to std::cout。說它熟悉是因?yàn)閹缀趺總€(gè) C/C 初學(xué)者都會(huì)被它攔住一次更離譜的是很多人查了半天代碼發(fā)現(xiàn)自己寫得一點(diǎn)問題都沒有。后來才明白問題壓根不在代碼而在編譯和鏈接這兩個(gè)階段上。所以我想把 C/C 編譯鏈接這一整套鏈路以及基本庫(kù)這個(gè)概念徹底拆開講明白編譯到底分幾步、鏈接器在做什么、靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)怎么選、環(huán)境怎么搭、報(bào)錯(cuò)怎么查。內(nèi)容不做太多理論糾纏全部是實(shí)操里沉淀下來的經(jīng)驗(yàn)適合剛?cè)腴T C/C以及正在跟各種鏈接錯(cuò)誤較勁的同學(xué)。1. 從源碼到目標(biāo)文件編譯過程的四道工序與報(bào)錯(cuò)定位1.1 四道工序各自在干什么很多人在終端里敲一句gcc hello.c -o hello管這叫編譯。這句話確實(shí)能幫你生成可執(zhí)行文件但它背后發(fā)生的事情遠(yuǎn)比一條命令復(fù)雜。加上-v參數(shù)運(yùn)行一遍你能看到驅(qū)動(dòng)程序依次調(diào)用了cc1真正的編譯器、as匯編器、collect2和ld鏈接器。也就是說這條命令最少拆成四個(gè)階段才完整。第一階段是預(yù)處理。運(yùn)行g(shù)cc -E hello.c -o hello.i做的是頭文件展開、宏替換、條件編譯分支選擇。你寫了一句#include stdio.h預(yù)處理階段會(huì)把stdio.h的完整內(nèi)容原樣粘貼到源文件里。一個(gè)普通的 hello 程序預(yù)處理之后文件體積能瞬間膨脹到幾千行。如果你看到的報(bào)錯(cuò)是某個(gè)頭文件找不到多半就在這一步翻車。第二階段是編譯。gcc -S hello.i -o hello.s把預(yù)處理后的代碼翻譯成匯編語言同時(shí)做嚴(yán)格的語法和類型檢查。項(xiàng)目里最耗時(shí)的優(yōu)化動(dòng)作-O2、-O3也發(fā)生在這一步幾十萬行的工程編譯半天大頭全在這里。編譯報(bào)錯(cuò)的表現(xiàn)是報(bào)錯(cuò)信息里帶有具體的源碼行號(hào)還會(huì)用^指向出問題的位置這類錯(cuò)誤是語法或類型層面的直接改代碼就行。第三階段是匯編。gcc -c hello.s -o hello.o把匯編代碼翻譯成機(jī)器指令生成目標(biāo)文件。Linux 下這個(gè)文件是 ELF 格式Windows 下是 COFF 格式。但此時(shí)的hello.o到處都是坑它引用了printf、memcpy這類外部符號(hào)卻還不知道這些符號(hào)在最終程序里的內(nèi)存地址。第四階段是鏈接。把多個(gè).o文件、庫(kù)文件拼裝成最終可執(zhí)行文件完成符號(hào)解析和地址重定位。gcc hello.o -o hello跑的就是這一步。絕大多數(shù)讓新手頭皮發(fā)麻的報(bào)錯(cuò)比如undefined reference、multiple definition都是在這一階段丟出來的。1.2 按報(bào)錯(cuò)信息快速判斷問題出在第幾步這四步對(duì)應(yīng)的報(bào)錯(cuò)形態(tài)差別非常大學(xué)會(huì)一眼判斷能省下大量無用的排查。預(yù)處理錯(cuò)誤通常是fatal error: xxx.h: No such file or directory解決方案是檢查-I參數(shù)和頭文件路徑。編譯錯(cuò)誤報(bào)錯(cuò)帶源碼行號(hào)內(nèi)容多為syntax error、類型不匹配、變量未聲明直接改代碼。匯編錯(cuò)誤日常業(yè)務(wù)代碼中很少見基本出現(xiàn)在內(nèi)聯(lián)匯編寫法不對(duì)或者目標(biāo)平臺(tái)不支持的指令集上。鏈接錯(cuò)誤報(bào)錯(cuò)帶符號(hào)名但不帶源碼行號(hào)比如undefined reference to bar、cannot find -lfoo、multiple definition of bar?？吹竭@類報(bào)錯(cuò)請(qǐng)先停止檢查語法轉(zhuǎn)去檢查你有沒有把正確的庫(kù)喂給鏈接器。提示編譯錯(cuò)誤是你話沒說對(duì)鏈接錯(cuò)誤是你需要的工具沒帶齊。記住這句話報(bào)錯(cuò)定位會(huì)快很多。鏈接階段要去找?guī)爝@也是基本庫(kù)這個(gè)概念登場(chǎng)的時(shí)機(jī)。庫(kù)分運(yùn)行時(shí)庫(kù)、靜態(tài)庫(kù)、動(dòng)態(tài)庫(kù)每一種在鏈接鏈路里的作用都不一樣。2. 基本庫(kù)到底是個(gè)什么東西運(yùn)行時(shí)庫(kù)、靜態(tài)庫(kù)與動(dòng)態(tài)庫(kù)的分工2.1 運(yùn)行時(shí)庫(kù)程序出生前就必須存在的底座基本庫(kù)在不同語境下指的東西不一樣但最核心的永遠(yuǎn)是運(yùn)行時(shí)庫(kù)。C 語言有 libcLinux 上通常是 glibc資源受限的嵌入式環(huán)境里常見 muslC 有 libstdcGCC 配套和 libcClang 配套Windows 上還有 UCRT、MSVC CRT 這類東西。只要你寫 C/C這些庫(kù)就是繞不開的底座。printf、malloc、new、delete、std::vector、std::cout的實(shí)現(xiàn)全部封裝在里面。這里有一個(gè)初學(xué)者必踩的經(jīng)典坑gcc和g的區(qū)別。用gcc去編譯一個(gè).cpp文件編譯階段沒問題到鏈接階段就會(huì)報(bào)undefined reference to std::cout一類錯(cuò)誤原因是gcc這個(gè)驅(qū)動(dòng)在鏈接時(shí)默認(rèn)不帶 C 運(yùn)行時(shí)庫(kù)。正確做法是編譯 C 用g。g本質(zhì)上也是調(diào)用同一個(gè)編譯器只是會(huì)在鏈接命令里自動(dòng)追加-lstdc。你不信的話給編譯命令加上-v看看它傳給鏈接器的參數(shù)就明白了。2.2 靜態(tài)庫(kù)與動(dòng)態(tài)庫(kù)兩種封裝形態(tài)的取舍庫(kù)本身又以兩種形態(tài)存在。靜態(tài)庫(kù)在 Linux 下是.a文件Windows 下是.lib。它本質(zhì)上是多個(gè)目標(biāo)文件打包在一起的壓縮包用ar rcs libcalc.a add.o sub.o就能生成。鏈接器在處理靜態(tài)庫(kù)時(shí)會(huì)把用到的目標(biāo)文件完整復(fù)制進(jìn)可執(zhí)行文件所以最終程序不需要依賴外部庫(kù)文件。動(dòng)態(tài)庫(kù)在 Linux 下是.soWindows 下是.dllmacOS 下是.dylib。鏈接階段只會(huì)檢查符號(hào)是否存在并記錄依賴關(guān)系和符號(hào)偏移真正的代碼加載發(fā)生在程序運(yùn)行時(shí)。好處是多個(gè)程序可以共享同一份庫(kù)文件更新庫(kù)只需要替換文件壞處是會(huì)出現(xiàn)所謂依賴地獄——換一臺(tái)機(jī)器可執(zhí)行文件就可能因?yàn)檎也坏侥硞€(gè).so而直接拒絕啟動(dòng)。對(duì)比項(xiàng)靜態(tài)庫(kù)動(dòng)態(tài)庫(kù)常見后綴.a/.lib.so/.dll/.dylib鏈接期行為目標(biāo)文件復(fù)制進(jìn)程序只登記符號(hào)依賴運(yùn)行期依賴無依賴庫(kù)文件存在且版本匹配可執(zhí)行文件體積偏大偏小更新庫(kù)需要重新編譯程序替換庫(kù)文件即可部署復(fù)雜度低高選擇的標(biāo)準(zhǔn)其實(shí)很樸素追求獨(dú)立部署、環(huán)境不可控優(yōu)先靜態(tài)鏈接追求體積小、更新靈活選動(dòng)態(tài)庫(kù)。另外-static參數(shù)可以強(qiáng)制全程靜態(tài)鏈接。我在排查動(dòng)態(tài)庫(kù)沖突問題時(shí)經(jīng)常臨時(shí)編一個(gè)靜態(tài)版本做對(duì)照組如果靜態(tài)版一切正?；究梢詳喽▎栴}出在動(dòng)態(tài)庫(kù)加載的環(huán)節(jié)。2.3 親手做出并鏈接一個(gè)基本庫(kù)命令行里創(chuàng)建庫(kù)并不神秘。假設(shè)你寫了一個(gè)計(jì)算器提供add和sub兩個(gè)函數(shù)# 編譯生成目標(biāo)文件 gcc -c add.c sub.c # 創(chuàng)建靜態(tài)庫(kù) libcalc.a ar rcs libcalc.a add.o sub.o # 編譯主程序并鏈接靜態(tài)庫(kù) gcc main.c -L. -lcalc -o main-L.告訴鏈接器在當(dāng)前目錄搜索庫(kù)文件-lcalc告訴它找一個(gè)叫l(wèi)ibcalc.a或libcalc.so的文件。注意 Linux 庫(kù)的命名規(guī)則文件必須叫l(wèi)ib加庫(kù)名再加后綴寫-l時(shí)既不帶lib前綴也不帶后綴。如果你把庫(kù)文件名起成calc.a而不是libcalc.a就算路徑對(duì)了鏈接器照樣找不到。動(dòng)態(tài)庫(kù)的命令稍稍多一點(diǎn)gcc -c -fPIC add.c sub.c gcc -shared -fPIC -o libcalc.so add.o sub.o gcc main.c -L. -lcalc -o main-fPIC表示生成位置無關(guān)代碼這是動(dòng)態(tài)庫(kù)的硬性要求。原因在于動(dòng)態(tài)庫(kù)在運(yùn)行時(shí)被映射到進(jìn)程地址空間的哪個(gè)位置不確定代碼內(nèi)部的跳轉(zhuǎn)和引用不能寫死絕對(duì)地址。3. 鏈接器的工作細(xì)節(jié)符號(hào)解析、庫(kù)順序與搜索路徑3.1 符號(hào)表、重定位與目標(biāo)文件里的坑鏈接器干的事情概括起來就兩件符號(hào)解析和重定位。符號(hào)解析是把代碼里所有對(duì)外部符號(hào)的引用和某個(gè)目標(biāo)文件或庫(kù)里的定義對(duì)上。每個(gè)目標(biāo)文件都有一張符號(hào)表用nm main.o就能看到。輸出里的T表示已經(jīng)定義的全局代碼符號(hào)U表示未定義、等著鏈接器去外面找的符號(hào)。我用這個(gè)命令排查過大量 undefined reference 問題把一個(gè)符號(hào)在它聲稱依賴的庫(kù)文件里跑一遍nm如果顯示為T說明它確實(shí)定義在這里如果到處都找不到那要么庫(kù)沒鏈接要么鏈接順序不對(duì)要么符號(hào)被 C 名字修飾過了。重定位則是在把所有目標(biāo)文件合并到一起后把代碼里那些懸空的符號(hào)引用替換成最終運(yùn)行時(shí)確定的虛擬內(nèi)存地址。這也是為什么一個(gè)簡(jiǎn)單的程序也要經(jīng)過鏈接才能跑起來——目標(biāo)文件里的代碼地址都是空的程序無法直接被操作系統(tǒng)加載。3.2 庫(kù)鏈接順序?yàn)槭裁词?GNU 工具鏈的經(jīng)典坑GNU ld 在處理靜態(tài)庫(kù)時(shí)有一個(gè)小脾氣它只會(huì)提取能夠解決當(dāng)前未定義符號(hào)的目標(biāo)文件而且默認(rèn)從左到右只掃描一遍。這就導(dǎo)致庫(kù)的書寫順序會(huì)直接影響鏈接成敗。假設(shè)libbar.a引用了libfoo.a里的符號(hào)鏈接命令必須寫成gcc main.o -lbar -lfoo -o app如果你顛倒次序?qū)懗?lfoo -lbar鏈接器掃描libfoo.a時(shí)發(fā)現(xiàn)沒有任何人引用它的符號(hào)直接跳過掃到libbar.a時(shí)才發(fā)現(xiàn)需要libfoo.a里的東西可這時(shí)libfoo.a已經(jīng)被處理完了于是報(bào)出 undefined reference。解決的辦法有兩個(gè)一是把依賴別人的庫(kù)寫在前面二是用--start-group和--end-group把多個(gè)庫(kù)包起來讓鏈接器反復(fù)掃描直到?jīng)]有新符號(hào)被解析出來gcc main.o -Wl,--start-group -lbar -lfoo -Wl,--end-group -o app我在真實(shí)項(xiàng)目里見過有人為了這種順序問題折騰一整天最后發(fā)現(xiàn)只是兩個(gè)-l參數(shù)調(diào)換一下順序。如果你用 CMake 管理項(xiàng)目這類問題會(huì)被工具鏈自動(dòng)處理掉這也是我推薦 CMake 的原因之一。3.3 -I、-L、-l 與運(yùn)行時(shí)搜索路徑的職責(zé)邊界-I是頭文件搜索路徑編譯時(shí)用-L是庫(kù)文件搜索路徑鏈接時(shí)用-l指定庫(kù)名也是鏈接時(shí)用。三者各管一段經(jīng)常有人混為一談。頭文件找不到時(shí)查-I庫(kù)文件找不到時(shí)查-L和文件名前綴規(guī)則符號(hào)未定義時(shí)查-l是否遺漏。比鏈接期搜索路徑更隱蔽的是運(yùn)行期搜索路徑。開發(fā)機(jī)上編譯通過、運(yùn)行得好好的程序拷到另一臺(tái)機(jī)器上彈出一句error while loading shared libraries: libcalc.so.1: cannot open shared object file。原因很簡(jiǎn)單動(dòng)態(tài)鏈接器ld.so只會(huì)在系統(tǒng)默認(rèn)目錄和它配置過的目錄里找?guī)旄静粫?huì)看你的當(dāng)前目錄。Linux 下的解決思路有三條設(shè)置環(huán)境變量LD_LIBRARY_PATH/path/to/libs后運(yùn)行臨時(shí)生效適合調(diào)試。把庫(kù)路徑寫入/etc/ld.so.conf.d/下的配置文件然后執(zhí)行l(wèi)dconfig全局生效。在編譯階段就把路徑寫進(jìn)可執(zhí)行文件叫 rpathgcc main.c -L. -lcalc -Wl,-rpath,$ORIGIN -o main。$ORIGIN表示可執(zhí)行文件所在目錄這個(gè)方案對(duì)發(fā)布軟件最友好。如果放在 Makefile 里記得寫成$$ORIGIN不然$ORIGIN會(huì)被 Make 當(dāng)成變量展開。用ldd ./main可以查看可執(zhí)行文件依賴了哪些動(dòng)態(tài)庫(kù)哪些找到了、哪些顯示為not found一眼便知。這是排查運(yùn)行時(shí)缺庫(kù)的第一命令沒有之一。4. 環(huán)境搭建實(shí)操命令行、VSCode 與 CMake 的完整鏈路4.1 編譯器選型GCC、Clang、MSVC 還是 MinGW-w64不同平臺(tái)、不同用途最順手的編譯器不一樣先看一張對(duì)比表編譯器常見平臺(tái)默認(rèn) C 運(yùn)行庫(kù)適用場(chǎng)景GCC / GLinux、嵌入式libstdc最通用近場(chǎng)部署首選Clang / ClangmacOS、Linuxlibc 或 libstdc報(bào)錯(cuò)提示友好現(xiàn)代特性跟進(jìn)快MSVCWindowsUCRT / MSVC CRTWindows 原生開發(fā)、大量 Windows SDKMinGW-w64Windowslibstdc 或 libc想在 Windows 上沿用 GCC 命令習(xí)慣一個(gè)非常重要的提醒MSVC 和 MinGW-w64 的庫(kù)不要混著用。兩者生成的庫(kù)雖然都是 Windows 上的二進(jìn)制格式但各自綁定不同的運(yùn)行時(shí)庫(kù)混用時(shí)能冒出各種匪夷所思的鏈接錯(cuò)誤。選定一條路就走到黑Windows 上用 Visual Studio 的同學(xué)堅(jiān)持 MSVC 工具鏈用命令行習(xí)慣的同學(xué)就堅(jiān)持 MinGW-w64。這兩個(gè)也不要同時(shí)在命令行環(huán)境里搶 PATH很亂。4.2 命令行下最快跑通一套開發(fā)環(huán)境以 Linux 或 macOS 為例最快的驗(yàn)證方式cat hello.cpp EOF #include iostream int main() { std::cout hello, world std::endl; return 0; } EOF g hello.cpp -o hello ./hellomacOS 上有個(gè)額外的坑系統(tǒng)自帶的g其實(shí)是指向 Clang 的符號(hào)鏈接也就是clang。很多時(shí)候這并不影響使用但如果你在 GitHub 項(xiàng)目要求必須用 GCC 真身得先確認(rèn)一下。Windows 上裝好 MinGW-w64 之后最常見的問題是在終端敲g提示不是內(nèi)部或外部命令。這不是編譯器沒裝上而是你沒把安裝目錄下的bin文件夾加進(jìn)系統(tǒng)的 PATH 環(huán)境變量。加上之后重啟終端就好。4.3 VSCode 配置 C/C 環(huán)境三個(gè)配置文件各管什么VSCode 本身不編譯、不運(yùn)行、不調(diào)試 C/C它只是一個(gè)編輯器前端。你先去擴(kuò)展市場(chǎng)裝一個(gè) C/C 擴(kuò)展ms-vscode.cpptools沒有它后面提到的cppdbg調(diào)試類型根本不會(huì)被識(shí)別。所謂配置 C/C 環(huán)境實(shí)際上是配好三個(gè)配置文件。第一個(gè)是tasks.json定義構(gòu)建任務(wù)。按下CtrlShiftB時(shí)會(huì)執(zhí)行{ version: 2.0.0, tasks: [ { label: build hello, type: shell, command: g, args: [-g, hello.cpp, -o, hello], group: {kind: build, isDefault: true} } ] }第二個(gè)是launch.json定義調(diào)試會(huì)話。按下F5時(shí)它會(huì)啟動(dòng)調(diào)試器{ version: 0.2.0, configurations: [ { name: debug hello, type: cppdbg, request: launch, program: ${workspaceFolder}/hello, args: [], cwd: ${workspaceFolder}, MIMode: gdb } ] }macOS 上默認(rèn)調(diào)試器是 lldbMIMode要寫成lldb否則會(huì)報(bào)找不到調(diào)試器。這是不少 mac 用戶在 VSCode 里按 F5 沒反應(yīng)的原因。第三個(gè)是c_cpp_properties.json它負(fù)責(zé)的是編輯器的 IntelliSense代碼補(bǔ)全、跳轉(zhuǎn)定義、紅波浪線。它只影響編輯體驗(yàn)不影響實(shí)際編譯。很多同學(xué)把 includePath 改來改去以為編譯行為會(huì)變化其實(shí)編譯只受tasks.json里寫的那條命令控制。includePath 建議直接指到編譯器自帶的頭文件目錄Linux 上是/usr/includeMinGW 的安裝目錄下也有對(duì)應(yīng)的include文件夾。4.4 用 CMake 告別手寫鏈接命令一旦項(xiàng)目里出現(xiàn)了多個(gè)源文件、多個(gè)庫(kù)再靠手寫g參數(shù)就有點(diǎn)吃力了CMake 是更穩(wěn)的選擇。一個(gè)最小可用的CMakeLists.txtcmake_minimum_required(VERSION 3.16) project(calc_app) add_executable(app main.cpp) add_library(calc add.cpp sub.cpp) target_include_directories(calc PUBLIC .) target_link_libraries(app PRIVATE calc)target_link_libraries會(huì)按依賴關(guān)系自動(dòng)處理鏈接順序這是它對(duì)我最大的價(jià)值——再也不用手工排列-l的先后次序。使用 CMake 時(shí)有一個(gè)非常容易出現(xiàn)、又非常好解決的坑改了CMakeLists.txt之后舊有的構(gòu)建緩存不會(huì)自動(dòng)全部失效有時(shí)行為會(huì)變得詭異。最干凈的處置就是刪掉 build 目錄重新配置一次。新加了源文件、換了庫(kù)依賴之后感覺哪都不對(duì)先別查代碼刪 build 重來很多情況下問題直接消失。5. 常見鏈接錯(cuò)誤實(shí)戰(zhàn)排查從一條報(bào)錯(cuò)挖到根因5.1 高頻鏈接錯(cuò)誤速查表報(bào)錯(cuò)信息根因排查方向undefined reference to xxx符號(hào)未定義庫(kù)是否漏鏈、順序是否顛倒、函數(shù)名是否拼錯(cuò)、C/C 混編未加 extern Ccannot find -lxxx庫(kù)文件找不到-L路徑是否正確、文件名是否帶lib前綴、庫(kù)是 32 位還是 64 位multiple definition of xxx符號(hào)重復(fù)定義頭文件里是否寫了全局變量定義、多個(gè)庫(kù)是否都定義了同名符號(hào)error while loading shared libraries運(yùn)行時(shí)找不到動(dòng)態(tài)庫(kù)用ldd查看依賴設(shè)置LD_LIBRARY_PATH或 rpathrelocation ... can not be used when making a shared object編譯選項(xiàng)不一致生成動(dòng)態(tài)庫(kù)時(shí)是否全程加了-fPICundefined reference to __gxx_personality_v0用 gcc 鏈接了 C 代碼改用g或顯式添加-lstdc這張表不能覆蓋所有情況但能覆蓋我遇到過的 90%。5.2 兩個(gè)真實(shí)案例第三方庫(kù)順序與 C/C 混編第一個(gè)案例來自一次第三方 SDK 接入。程序引入了libsdk.a編譯階段一切順利鏈接時(shí)冒出一串 undefined reference仔細(xì)看報(bào)錯(cuò)符號(hào)都指向 OpenSSL 的函數(shù)。當(dāng)時(shí)的直覺是-lssl -lcrypto沒加加上之后照樣報(bào)錯(cuò)。后來用nm libsdk.a | grep SSL確認(rèn)符號(hào)確實(shí)沒定義又檢查了系統(tǒng)里libssl.so也真實(shí)存在。最終定位到問題-lssl -lcrypto寫在了libsdk.a前面鏈接器掃描 OpenSSL 庫(kù)時(shí)尚未發(fā)現(xiàn)任何未定義符號(hào)直接跳過去了。修復(fù)就是把這兩個(gè)參數(shù)移動(dòng)到 SDK 庫(kù)之后或者直接用 CMake 聲明依賴關(guān)系。第二個(gè)案例是 C 和 C 混編。同事在 C 項(xiàng)目里調(diào)用一個(gè) C 靜態(tài)庫(kù)函數(shù)名、路徑、庫(kù)文件全都對(duì)得上但鏈接器總報(bào)undefined reference to my_c_function。用nm查庫(kù)文件發(fā)現(xiàn)函數(shù)在庫(kù)里明明存在再看末尾C 那邊引用的符號(hào)已經(jīng)被名字修飾成了_Z14my_c_functionv兩個(gè)名字根本對(duì)不上。原因在于 C 編譯器會(huì)把函數(shù)名按照一定的規(guī)則攪碎變成帶類型信息的長(zhǎng)符號(hào)而 C 編譯器不會(huì)。修復(fù)方法是在 C 側(cè)把 C 的頭文件用extern C包起來extern C { #include c_api.h }這兩個(gè)案例說明同一個(gè)道理鏈接錯(cuò)誤往往不是代碼邏輯不對(duì)而是符號(hào)對(duì)不上。5.3 排查鏈接問題必備的命令行工具nm查看目標(biāo)文件和庫(kù)的符號(hào)表判斷符號(hào)定義在哪、有沒有被名字修飾。ldd查看可執(zhí)行文件的動(dòng)態(tài)庫(kù)依賴找出運(yùn)行時(shí)缺了誰。readelf -d查看 ELF 文件的動(dòng)態(tài)段信息搜索路徑、依賴庫(kù)版本都能看到。objdump -t以更底層的視角查看符號(hào)。LD_DEBUGlibs ./main讓動(dòng)態(tài)鏈接器打印加載過程能看清它按什么順序搜索了哪些目錄這個(gè)調(diào)試手段在定位運(yùn)行時(shí)加載問題時(shí)極其好用。strace -e openat ./main在 Linux 上跟蹤文件打開調(diào)用看看程序到底去哪些路徑找過庫(kù)文件。把這幾條命令組合起來用鏈接類的報(bào)錯(cuò)基本都能快速定位。我個(gè)人的習(xí)慣是遇到鏈接錯(cuò)誤第一件事永遠(yuǎn)不是改代碼而是打開終端跑一條nm和一條ldd先搞清楚問題到底是符號(hào)不存在還是定義沒有被找到。這兩個(gè)方向?qū)?yīng)的解法截然不同想清楚再動(dòng)手能節(jié)省大量瞎試的時(shí)間。另外如果你的項(xiàng)目將來要在多個(gè)平臺(tái)之間搬動(dòng)建議早點(diǎn)從手寫gcc參數(shù)切到 CMake短期看多寫了幾行文件長(zhǎng)期看省掉的是無數(shù)個(gè)人為排庫(kù)順序的深夜。