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