簡介面向在Windows 7 64位平臺為Python 2.7配置GDAL的開發(fā)者這份docx格式的安裝筆記給出了完整的環(huán)境準備與排錯指引。文檔先是說明需要預(yù)裝Visual Studio 2010、GEOS 3.3.8與Python 2.7隨后對比了兩條安裝路徑基于GDAL core源碼自帶的SWIG/Python接口自行編譯以及直接下載官方MSI安裝包前者適合希望理解底層構(gòu)建的讀者后者則更為簡便。針對源碼編譯中常見的SWIG工具缺失、VS2010編譯環(huán)境變量問題以及安裝完成后import gdal時DLL加載失敗等情況文檔都給出了對應(yīng)的環(huán)境變量配置與排錯思路并附有完整錯誤信息附錄方便快速定位問題。資源為單個docx文件僅95KB便于隨身查閱已有628人學(xué)習(xí)下載適合剛接觸GDAL的Python用戶在搭建GDAL環(huán)境時作為對照參考。1. import gdal 報 DLL load failed一晚上卡在“找不到指定的模塊”「DLL load failed: 找不到指定的模塊」這句話放在 GDAL、Python 2.7、Win7 64 位這套組合里足夠讓一個人折騰掉整個周末。報錯只有一行不告訴你是哪個 DLL 掉了鏈子也不提示該往哪個目錄補環(huán)境變量有人反復(fù)重裝 msi有人重新編譯源碼最后發(fā)現(xiàn)真正的坑往往就藏在 PATH 里。我把兩條安裝路線——源碼編譯和 msi 直裝——分別踩過的報錯、根因和解決命令梳理成一份可以直接照做的排查路徑。新手可以按命令一步步執(zhí)行熟手可以直接翻到第六章看快速定位技巧。別再像我當年一樣在同一個 DLL 報錯上消耗一個周末。2. 裝 GDAL 前先看清環(huán)境版本、依賴與雙路線怎么選2.1 為什么 Win7 64 位加 Python 2.7 特別容易出 DLL 問題先明確一個概念在 Windows 上 import gdal 不是普通的 Python 模塊加載。GDAL 本體是 C/C 庫Python 要調(diào)用它靠的是 SWIG 生成的綁定層。真正的調(diào)用鏈是 Python 解釋器先加載 osgeo/_gdal.pyd然后 _gdal.pyd 再去加載 gdal192.dll最后由 gdal192.dll 依賴 C 運行庫。鏈條上任何一環(huán)的 DLL 不在搜索路徑里、位數(shù)不匹配、或編譯工具鏈對不上最終拋給用戶的都是同一句「DLL load failed: 找不到指定的模塊」。這就是為什么很多人裝完 GDAL 后第一步就懵——報錯信息完全沒告訴你問題出在哪一環(huán)。Win7 64 位這個平臺之所以難纏是因為它同時存在兩種 Python32 位版和 64 位版。很多人看到系統(tǒng)是 64 位就默認下載 64 位 GDAL卻忽略了 Python 解釋器本身可能是 32 位。解釋器位數(shù)和 DLL 位數(shù)不一致時報錯會變成「不是有效的 Win32 應(yīng)用程序」又是另一番折騰。另外官方 Python 2.7 主要用 VS2008 工具鏈編譯而 GDAL 在 Win7 64 位下常見的編譯環(huán)境是 VS2010工具鏈版本錯位會直接引發(fā)后面那個經(jīng)典的 unable to find Vcvarsall.bat。這些坑不是孤立出現(xiàn)的它們互相疊加才是安裝 GDAL 的真正難點。Windows 加載 DLL 時默認搜索順序大致是應(yīng)用程序所在目錄、系統(tǒng)目錄、Windows 目錄、當前工作目錄、PATH 環(huán)境變量里列出的目錄。對 Python 解釋器來說exe 所在目錄就是 Python27 目錄site-packages 不會出現(xiàn)在搜索順序里。所以當 _gdal.pyd 需要 gdal192.dll 時它只能順著 PATH 去找。這條機制貫穿全文后面三個報錯里至少有兩個最終都要回到 PATH 上解決。2.2 依賴清單GDAL 1.9.2、GEOS 3.3.8、SWIG 2.10.0 各管什么在動手之前先把需要用到的組件列清楚。下面這張表里每一項都是實際記錄過的版本號照著這個組合選版本踩坑概率會低很多。組件版本作用缺了會怎樣GDAL core1.9.2C 核心庫gdalinfo、ogr2ogr 等命令行工具由它提供沒有核心庫Python 綁定無從談起GEOS3.3.8空間幾何運算庫編譯或運行 GDAL 時被鏈接編譯期報缺頭文件運行期可能報找不到 GEOS DLLPython2.7腳本運行環(huán)境無法 importVS2010完整版含 C 編譯器nmake 與 setup.py build 都要靠它兩個方案都卡在編譯步驟SWIG2.10.0根據(jù) C 接口生成 Python 包裝代碼nmake 在 swig.exe 那一步直接中斷原文里提到了 GDAL 1.11.0 也能用但最終選擇 1.9.2理由是「資料多一些」。這一點在排錯場景下非常重要老版本的問題幾乎都被前人踩過網(wǎng)上的錯誤現(xiàn)場、截圖、解決方案一搜一大把照貓畫虎就能過新版本雖然功能新但遇到冷門報錯時能參考的記錄少排錯成本反而更高。所以如果你也是第一次在 Win7 64 位加 Python 2.7 上裝 GDAL我不是推薦你追新而是建議你跟這條已被驗證的路徑走。版本匹配還要遵循兩個原則。第一解釋器位數(shù)與 GDAL 位數(shù)必須一致這一點在 msi 直裝時尤其容易翻車。第二Python 2.7 與 GDAL 1.9.2、GEOS 3.3.8、SWIG 2.10.0 是一組被驗證過的組合不要只換其中一個版本而其它不變。單獨升級 GDAL 到 1.11.0DLL 名會變綁定層也要重新生成牽一發(fā)動全身。2.3 源碼編譯與 msi 直裝怎么選以目標決定路線兩條路線我都實驗過都能跑到 import gdal 成功。區(qū)別在于過程成本和你能得到什么。源碼編譯路線簡單說就是從 GDAL 的 C 源碼開始用 VS2010 的 nmake 構(gòu)建 core再用 swig 和 Python 的 distutils 構(gòu)建綁定層最終把 gdal.py 和 _gdal.pyd 安裝到 site-packages。這條路報錯最多但能看清 GDAL 讀數(shù)據(jù)的流程先讀 gdalinfo.cpp 了解入口再走 swig 目錄里的 makefile 理解綁定生成過程。如果你之后要改 GDAL 源碼或者要定制編譯參數(shù)只能走這條路。msi 直裝就簡單得多一路 Next 完事適合只想要一個能調(diào)用的 GDAL、不在乎內(nèi)部實現(xiàn)的場景。但它同樣有坑安裝包不會自動替你把 DLL 目錄加入 PATH裝完照樣報 DLL load failed。所以兩條路最終匯合在同一個動作上——把 GDAL 的 bin 目錄寫進 PATH。這也可以看作一個判斷標準如果你裝完之后 import 失敗先別看堆棧先去檢查 PATH。對比項源碼編譯msi 直裝安裝耗時長需要整條編譯鏈正確短雙擊即裝報錯數(shù)量多常見的三個坑都會遇到少但 DLL 報錯繞不開可定制性高可改源碼與編譯參數(shù)低對架構(gòu)的理解能理清 core、swig、python 的關(guān)系基本沒有適合人群要改源碼、要排底層問題的人只想讓 Python 調(diào)用 GDAL 的人如果你第一次裝又不想研究 C 編譯我建議直接走 msi 直裝遇到 DLL 報錯就按第 4 章處理如果你和我一樣非要把 core 的編譯流程弄明白那就按第 3 章的源碼路線走一遍踩坑本身就是收獲。3. 源碼編譯路線上的三個攔路報錯swig.exe、Vcvarsall.bat 與 DLL load failed源碼編譯路線總共會遇到三個標志性報錯順序也很固定先是 swig 工具缺失再是編譯器工具鏈找不到最后是裝完了 import 又倒在 DLL 上。接下來按我當時實際執(zhí)行的順序逐個拆。3.1 第一個報錯swig.exe 不是內(nèi)部或外部命令現(xiàn)象以管理員身份打開 VS2010 自帶的「X64 兼容工具命令提示符」切換到 GDAL 源碼解壓目錄下的 swig 目錄執(zhí)行 nmake /f makefile.vc python。輸出走到一半時突然出現(xiàn)一行swig.exe 不是內(nèi)部或外部命令也不是可運行的程序或批處理文件。隨后 nmake 直接退出錯誤碼 U1077。這個報錯的位置在 makefile 嘗試調(diào)用 swig 生成 gdalconst_wrap.c 的那一步說明前面的環(huán)境準備基本正?？ň涂ㄔ谌鄙?swig 這個代碼生成工具上。根因makefile 的 python 目標需要調(diào)用 swig.exe把 include 下的 C 頭文件翻譯成 Python 擴展的 C 包裝文件。機器上沒裝 swig系統(tǒng) PATH 里也沒有任何叫 swig 的可執(zhí)行文件所以 nmake 在子進程啟動時就失敗了。注意這里不是 GDAL 或 Python 的問題純粹是工具缺失。解決方式分兩步先安裝 swig 2.10.0再把它的可執(zhí)行文件目錄寫進 PATH。命令如下rem 進入 GDAL 源碼的 swig 目錄路徑按實際解壓位置替換 cd C:\OGC\GDAL192\gdal-1.9.2\swig rem 把 swig 解壓目錄臨時加進當前窗口的 PATH set PATHC:\swigwin-2.0.10;%PATH% rem 先驗證 swig 能用再重新執(zhí)行 nmake swig -version nmake /f makefile.vc python這段命令的意思是set PATH 把 swig 所在目錄接到現(xiàn)有 PATH 之前讓 nmake 啟動子進程時能找到 swig.exeswig -version 是為了在執(zhí)行耗時的編譯之前先確認工具真的可用避免改完 PATH 又跑一遍 nmake 才再次報錯。C:\swigwin-2.0.10 是我本機的解壓目錄你在實際環(huán)境中替換成自己的路徑即可。如果之后還要多次編譯建議把它追加到系統(tǒng)環(huán)境變量里省得每次開窗口都 set 一遍。這一步為什么要用 VS2010 的兼容工具命令提示符而不是普通 cmd因為 nmake 編譯過程中隨時要調(diào)用 cl.exe、link.exe 等編譯器與鏈接器這些工具只在這些專用命令行窗口里才默認可用。普通 cmd 打開后就算 GDAL 源碼沒問題也會在找不到 cl.exe 處再次中斷白折騰一輪。3.2 第二個報錯unable to find Vcvarsall.bat現(xiàn)象swig 問題解決后切換到 swig/python 目錄執(zhí)行 python setup.py build。這一次編譯工具找到了但 distutils 在初始化編譯環(huán)境時報錯unable to find Vcvarsall.bat。這個報錯對用過 Python 2.7 裝 C 擴展的人來說應(yīng)該非常眼熟。根因官方 Python 2.7 的構(gòu)建工具鏈是 VS2008對應(yīng)編譯器版本是 VC9。distutils 在 build 擴展模塊時會讀取環(huán)境變量 VS90COMNTOOLS 指向的路徑然后去那里找 vcvarsall.bat 來初始化 MSVC 環(huán)境。而我們的機器上只有 VS2010它設(shè)置的環(huán)境變量是 VS100COMNTOOLS對應(yīng) VC10。distutils 只認 VS90 開頭的變量找不到就放棄報出這個錯誤。網(wǎng)上有一種方案是用 MinGW 配合 --compilermingw32 繞過 MSVC我實驗過失敗了。原因很現(xiàn)實swig 生成的包裝 C 文件依賴 MSVC 的頭文件和鏈接庫MinGW 的包含路徑和鏈接參數(shù)很難一次對齊折騰出的新報錯比原來更多。最簡單的路反而是「騙過 distutils」——把現(xiàn)有 VS2010 的工具目錄臨時安到 VS90COMNTOOLS 名下。rem 當前窗口內(nèi)臨時對齊工具鏈版本 Set VS90COMNTOOLS%VS100COMNTOOLS% rem 重新執(zhí)行構(gòu)建與安裝 python setup.py build python setup.py install這個 set 的含義是把 VS2010 的 Tools 目錄路徑復(fù)制給 VS90COMNTOOLS讓 distutils 誤以為 VS2008 工具鏈存在。它只對當前命令行窗口生效關(guān)掉窗口就失效不會寫進注冊表或系統(tǒng)環(huán)境這點對不想污染環(huán)境的場景很友好。執(zhí)行 build 和 install 時屏幕上會刷出很多提示注意區(qū)分只要不是 error 或 fatal error基本可以忽略下一節(jié)專門講怎么看這些輸出。順帶解釋一下這兩條命令的分工。python setup.py build 負責(zé)把 swig 生成的 C 包裝文件編譯成 _gdal.pyd并處理與 gdal192.dll 的鏈接python setup.py install 則負責(zé)把 gdal.py、osgeo 包和擴展模塊復(fù)制到 site-packages 目錄。只有 install 成功import 時才能從 site-packages 找到模塊文件。3.3 第三個報錯ImportError: DLL load failed: 找不到指定的模塊現(xiàn)象setup.py install 執(zhí)行完沒有任何紅色報錯。打開 Python 命令行import gdal結(jié)果又拋出一堆堆棧最后幾行落在File C:\Program Files (x86)\Python27\lib\site-packages\osgeo_init_.py, line 17, in swig_import_helper _mod imp.load_module(_gdal, fp, pathname, description) ImportError: DLL load failed: 找不到指定的模塊。這個報錯出現(xiàn)得最頻繁也最讓人崩潰它明明說「找不到指定的模塊」卻沒告訴我們到底是哪個模塊。根因此時 gdal.py 和 osgeo/_gdal.pyd 都已經(jīng)在 site-packages 里Python 能找到它們。但 _gdal.pyd 在加載時還要進一步去加載 gdal192.dllgdal192.dll 所在目錄是 GDAL 安裝目錄下的 bin而這個 bin 不在 PATH 里。Windows 的 DLL 搜索機制找不到它于是整個 load_module 過程以「找不到指定的模塊」收場。報錯信息之所以含糊是因為 LoadLibrary 返回的錯誤碼只表達了「某個依賴 DLL 不存在」但不會告訴你是鏈條上的哪一個。解決方式其實極其簡單就是把 GDAL 的 bin 目錄加進 PATH。命令如下rem 先確認 GDAL 的 bin 目錄路徑以下為 msi 安裝的默認位置 set PATHC:\Program Files\GDAL192\bin;%PATH% rem 驗證加載是否成功能打印版本號就說明 DLL 找到了 python -c from osgeo import gdal; print(gdal.VersionInfo())如果你走的是源碼編譯路線bin 目錄一般就是 GDAL 源碼編譯產(chǎn)物的輸出目錄如果走的是 msi 路線通常是 C:\Program Files\GDAL192\bin具體以你的安裝位置為準。上面這個 set 同樣只對當前窗口有效建議驗證通過后把它追加到系統(tǒng)環(huán)境變量 Path 中然后重新打開命令行窗口。如果加了 PATH 仍然報錯我一般會再做兩步定位。第一步執(zhí)行 where gdal192.dll看看系統(tǒng)能不能在 PATH 里找到這個 DLL如果 where 有輸出但 Python 還是報錯就去檢查 PATH 里目錄的拼寫和版本號。第二步直接用 dir 確認那個 bin 目錄真實存在并看著文件列表里確實有 gdal192.dll。很多時候卡住的不是配置邏輯而是路徑寫錯了比如版本目錄名寫成了 GDAL110實際解壓目錄卻是 GDAL192。3.4 編譯途中刷屏的「問題」怎么區(qū)分 warning 與 error很多資料在講源碼編譯時都會來一句「會提示很多問題不用管它」。這句話不能無條件相信。我在編譯過程中見到的刷屏內(nèi)容絕大多數(shù)是 C 編譯器的 warning比如宏定義重復(fù)、隱式函數(shù)聲明、符號修飾符不匹配這些都是歷史代碼在新編譯器下的正常噪音不影響生成 _gdal.pyd 和 gdal.py可以略過。但如果輸出里出現(xiàn) error C2xxx、error LNK2xxx、fatal error 這些字樣就必須停下來。error C 開頭的通常是源文件編譯失敗的語法或類型問題error LNK 開頭的則是鏈接階段找不到符號或庫文件。這兩種情況再往后繼續(xù) build 也只是浪費編譯時間得先解決報錯本身。批量編譯輸出很長時我習(xí)慣把輸出重定向到文件再用 findstr 過濾關(guān)鍵行python setup.py build build.log 21 rem 只看錯誤行過濾掉 warning findstr /i error C error LNK fatal build.logfindstr 只匹配包含錯誤關(guān)鍵字的行讓長輸出變成幾行有效信息。這樣既能保留完整日志給后續(xù)排查又不會被幾百行 warning 淹沒。源碼編譯的耐心都花在這種細節(jié)上每一次重跑之前先確認上一輪的錯誤真的處理掉了再執(zhí)行下一條命令。4. msi 直裝也不省心DLL load failed 的最后一公里在 PATH4.1 msi 安裝步驟與版本位數(shù)的坑如果你不想碰源碼編譯第二種方案確實簡單很多下載對應(yīng)版本的 GDAL msi 安裝包雙擊一路 Next裝完就能開始。但「簡單」不等于「沒坑」。我實驗這條路時裝完 msi 后在 Python 里 import gdal同樣被那一句 DLL load failed 擋在門外而且和源碼編譯路線遇到的是同一個問題。先補一個關(guān)鍵檢查下載 msi 之前確認 Python 解釋器本身的位數(shù)。Win7 64 位系統(tǒng)只是一個基礎(chǔ)條件不保證你裝的 Python 是 64 位。很多官方安裝包默認下載的是 32 位 Python 2.7安裝路徑是 C:\Program Files (x86)\Python27。如果 Python 是 32 位就要選 win32 版 GDAL只有解釋器確實是 64 位版本時才選 64 位 msi。位數(shù)不匹配時報錯文案會變成「不是有效的 Win32 應(yīng)用程序」那不是 PATH 能解決的問題。判斷位數(shù)可以在命令行里執(zhí)行python -c import platform; print(platform.architecture())輸出 (64bit, ) 就是 64 位解釋器輸出 (32bit, ) 就是 32 位。這個信息比系統(tǒng)位數(shù)更準確因為它直接反映當前 Python 進程的位數(shù)。GDAL 是個 C/C 庫DLL 的位數(shù)必須和加載它的進程一致沒有任何兼容層可以繞過去。msi 裝完之后還有一個容易忽略的點默認安裝目錄通常是 C:\Program Files\GDAL192bin 子目錄里放著 gdal192.dll 和 gdalinfo.exe、ogr2ogr.exe 等工具。安裝過程不一定自動把 bin 寫進 PATH這也就是為什么很多人裝完 msi 后第一次 import 就報錯——他們以為安裝程序應(yīng)該全都配好了其實還差最后一公里。4.2 同一個 DLL 報錯bin 目錄加入 PATH 就是解藥msi 路線的報錯堆棧和源碼編譯路線完全一致site-packages 里的包文件都在imp.load_module(_gdal, ...) 時崩掉錯誤信息寫著「找不到指定的模塊」。根因也沒有任何區(qū)別——Python 進程加載 _gdal.pyd 時找不到 gdal192.dll。msi 只是把 DLL 放到了 GDAL 自己的安裝目錄并沒有告知 Python 解釋器去哪里找它。解決方案就是把 bin 目錄追加到 PATH。命令和上一章相同路徑以實際安裝位置為準rem msi 默認安裝位置的 bin 目錄按實際版本與目錄調(diào)整 set PATHC:\Program Files\GDAL192\bin;%PATH% python -c from osgeo import gdal; print(gdal.VersionInfo())這一次成功打印出版本號后再做持久化處理打開系統(tǒng)環(huán)境變量設(shè)置在 Path 的末尾追加 C:\Program Files\GDAL192\bin保存后重新打開命令行驗證。注意 Path 編輯時別把原有條目刪掉或把分隔符寫成全角分號Win7 的環(huán)境變量編輯器對格式很敏感改壞了會影響很多程序。有些 msi 在安裝時會詢問是否需要添加環(huán)境變量不同版本行為不一樣。如果你在安裝過程中發(fā)現(xiàn)了這個選項直接勾選會更省事但這通常只會寫入安裝階段的環(huán)境變量快照已打開的進程依然要重啟才能拿到。總之裝完 GDAL 后第一件事不是急著寫代碼而是先確認 PATH 里有 bin 目錄再談 import。4.3 改完 PATH「沒生效」環(huán)境變量生效范圍詳解這一節(jié)幾乎算是最常見的求助現(xiàn)場明明把 bin 目錄加進 PATH 了python -c from osgeo import gdal 還是報 DLL load failed。這不是 GDAL 的坑而是 Windows 環(huán)境變量的生效機制問題。第一個原因是進程快照。環(huán)境變量在進程啟動時被讀取并緩存在內(nèi)存里。你改完系統(tǒng) PATH 后當前已經(jīng)打開的命令行窗口不會重新加載新值它拿到的還是舊 PATH里面沒有 GDAL 的 bin 目錄。解決辦法很簡單完全關(guān)閉當前窗口再新開一個 cmd然后執(zhí)行 echo %PATH% 確認新路徑已經(jīng)出現(xiàn)在輸出里。如果輸出里都還沒有說明編輯沒保存或加錯了位置回頭檢查環(huán)境變量編輯器。第二個原因是 IDE 的 Python 控制臺。很多集成開發(fā)環(huán)境在啟動時一次性讀入環(huán)境變量即便你在外部改了 PATHIDE 內(nèi)嵌的控制臺仍然沿用舊值。遇到這種情況需要徹底重啟 IDE個別 IDE 還會緩存系統(tǒng)變量到配置里那時甚至要重啟機器才生效。這個現(xiàn)象很容易被誤判成「環(huán)境變量修改無效」其實是軟件生命周期的問題。第三個原因是 PATH 內(nèi)容順序。用戶變量和系統(tǒng)變量的 Path 最終會被拼接成一條完整路徑串系統(tǒng)變量通常在前用戶變量在后。如果你曾經(jīng)把舊版本 GDAL 的 bin 目錄放在靠前的位置現(xiàn)在新增的目錄又放在后面Windows 會優(yōu)先命中舊目錄里的 gdal192.dll導(dǎo)致版本號不對。所以改完 PATH 后不只要確認「有沒有」還要確認「順序?qū)Σ粚Α?。?zhí)行 echo %PATH%找到你的 GDAL 條目看它排在前面的其它 GDAL 目錄前面還是后面。5. 避坑清單GDAL 安裝與 import 的 5 個高頻翻車現(xiàn)場以下 5 條全部來自實際安裝記錄每一條都被不同的人以不同方式問起過。有些坑在前面章節(jié)已經(jīng)講過原理但現(xiàn)場提問時往往只給一句報錯不會附帶完整堆棧所以我把它們單獨拎出來按「現(xiàn)象 → 原因 → 解決」三段寫方便你對號入座。如果你遇到的問題不在清單里請先翻到第六章用表格里的處理順序定位一遍多半能找到答案。5.1 msi 裝了 import 還是報 DLL load failed現(xiàn)象msi 雙擊安裝成功GDAL 命令行工具也能用但 Python 里 import gdal 立刻拋 ImportError: DLL load failed: 找不到指定的模塊。原因安裝程序只把文件放到了 C:\Program Files\GDAL192沒有把其中的 bin 目錄寫進 PATHPython 加載 _gdal.pyd 時按默認 DLL 搜索路徑找不到 gdal192.dll。解決把 bin 目錄追加到系統(tǒng) Path 后新開命令行重新執(zhí)行 python -c from osgeo import gdal; print(gdal.VersionInfo()) 驗證。一定記得重開窗口否則會誤以為沒生效。5.2 32/64 位混裝DLL load failed: 不是有效的 Win32 應(yīng)用程序現(xiàn)象import gdal 時不是常見的「找不到指定的模塊」而是 DLL load failed: 不是有效的 Win32 應(yīng)用程序。原因GDAL DLL 的位數(shù)和 Python 解釋器位數(shù)不一致。常見場景是 64 位 Win7 上裝著 32 位 Python 2.7卻下載了 64 位 GDAL msiWindows 嘗試加載位數(shù)不符的 DLL 時直接拒絕。解決先執(zhí)行 python -c import platform; print(platform.architecture()) 確認解釋器位數(shù)再下載與之一致的 GDAL 版本。遇到這個報錯加 PATH 沒有用必須換安裝包。5.3 swig 明明裝了nmake 還是說不是內(nèi)部或外部命令現(xiàn)象明明下載并解壓了 swig也把目錄加入環(huán)境變量了執(zhí)行 nmake /f makefile.vc python 仍報 swig.exe 不是內(nèi)部或外部命令。原因多數(shù)情況是沒有把 swig.exe 實際所在的目錄加進 PATH只加了外層解壓目錄或者加入環(huán)境變量后當前命令行窗口沒有重新讀取。另一種情況是解壓工具生成的是 swig.exe 位于子目錄用戶憑印象寫錯了路徑。解決在文件管理器里定位到 swig.exe 的真實位置把那一級目錄加入 PATH然后新開命令行執(zhí)行 swig -version 確認輸出版本號再重跑 nmake。檢查時可以用 where swig 看系統(tǒng)實際找到了哪個 swig。5.4 Vcvarsall.bat 的 hack 重啟后又被卡住現(xiàn)象Set VS90COMNTOOLS%VS100COMNTOOLS% 后編譯順利通過第二天重新打開命令行再執(zhí)行 python setup.py build又報 unable to find Vcvarsall.bat。原因set 只對當前命令行會話臨時生效進程退出后環(huán)境變量恢復(fù)原樣。每次重開會話都要重新設(shè)置一次忘了就回到原點。解決兩種處理任選其一。其一把 VS90COMNTOOLS 寫進用戶環(huán)境變量值指向 VS2010 的 Tools 目錄一次設(shè)置長期生效其二在自己編寫的編譯腳本開頭保留這條 set把它當成步驟流程的一部分不要依賴記憶。哪種方式都要在重開后先 set再 build。5.5 裝了新 GDAL運行時加載的還是舊版本現(xiàn)象重新安裝了另一個版本的 GDAL代碼沒改但 gdal.VersionInfo() 輸出的版本號不是新裝的版本甚至功能表現(xiàn)和預(yù)期不一致。原因PATH 里同時存在新舊兩個 GDAL 的 bin 目錄舊目錄排在新目錄前面。Windows 按 PATH 順序查找 DLL先命中了舊版 gdal192.dll。解決打開環(huán)境變量編輯器把新版本的 bin 目錄移動到舊版本目錄之前或者直接刪除已經(jīng)不再使用的舊目錄條目。排查時不要靠安裝記錄判斷先跑 python -c from osgeo import gdal; print(gdal.VersionInfo()) 看實際加載的是哪個。6. 兩分鐘快速定位從報錯關(guān)鍵詞反推根因的排查順序面對 GDAL 安裝報錯最忌一上來就重裝、重編譯、翻源碼。實際上報錯文案本身就指了路。我把最高頻的四類報錯按關(guān)鍵詞整理成一張對照表遇到問題時先對號入座再按處理順序執(zhí)行大多數(shù)情況下不用動堆棧內(nèi)的 Python 代碼。報錯關(guān)鍵詞根因處理順序swig.exe 不是內(nèi)部或外部命令swig 未安裝或未加入 PATH安裝 swig 2.10.0 → 定位 swig.exe 目錄 → 加 PATH → 新開窗口驗證unable to find Vcvarsall.batPython 2.7 工具鏈與 VS 版本不匹配Set VS90COMNTOOLS%VS100COMNTOOLS% → 重跑 build → installDLL load failed: 找不到指定的模塊gdal192.dll 不在 DLL 搜索路徑where gdal192.dll 定位 → bin 目錄加 PATH → 重啟終端驗證DLL load failed: 不是有效的 Win32 應(yīng)用程序解釋器與 DLL 位數(shù)不一致查 python 位數(shù) → 下載對應(yīng)位數(shù) msi → 重裝No module named osgeo安裝進了別的 Python 環(huán)境where python 確認當前解釋器 → 在目標環(huán)境重裝配合這張表我一般會固定執(zhí)行四行命令把變量釘死再決定要不要重裝。命令如下rem 確認當前命令行實際使用的是哪個 Python where python rem 確認 PATH 里是否已經(jīng)包含 GDAL 的 bin 目錄 echo %PATH% rem 確認解釋器是 32 位還是 64 位 python -c import platform; print(platform.architecture()) rem 確認運行時真正加載的 GDAL 版本 python -c from osgeo import gdal; print(gdal.VersionInfo())where python 解決的是「我裝給了誰」的問題。機器上如果同時存在多個 Pythonsetup.py install 只作用于當時激活的那一個import 失敗的往往是另一個解釋器。echo %PATH% 解決的是「DLL 到底在哪找」的問題輸出里沒有 GDAL 的 bin 目錄后面做的任何操作都是白費。platform.architecture() 解決的是「位數(shù)匹配不匹配」的問題。VersionInfo 則直接告訴你 import 到的是哪個版本避免被環(huán)境里殘留的舊 DLL 欺騙。如果這四行命令結(jié)果都正常VersionInfo 也能輸出版本號那問題就脫離了安裝階段應(yīng)該回到業(yè)務(wù)代碼里排查比如數(shù)據(jù)格式、坐標系或驅(qū)動缺失。別在安裝環(huán)節(jié)繼續(xù)鉆牛角尖那已經(jīng)不是 PATH 能解釋的范圍了。從那以后我再裝任何帶原生擴展的庫只要 import 階段出現(xiàn) DLL 相關(guān)報錯第一件事就是跑這四行確認解釋器、PATH、位數(shù)三個變量都正常才去懷疑代碼和依賴本身。這個習(xí)慣幫我省掉了無數(shù)個深夜排查的時間。希望幫到你。本文還有配套的精品資源點擊獲取