本人在win10下安裝了mingw環境，以方面windows下測試gcc編譯器構建一些開源組件。但是windows系統下遇到了一些編譯問題。
1. 問題現象
一次手寫的Makefile遇到了如下編譯錯誤：
1 $ make 2 g++ -I ../include -fPIC -c JpegDecoder.cpp -o JpegDecoder.o 3 g++ -o JpegDecoder JpegDecoder.o -L../libs -lcodec_utils 4 d:/ProgramFiles/mingw-w64/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lcodec_utils 5 collect2.exe: error: ld returned 1 exit status 6 make: *** [JpegDecoder] Error 1
可是，在linux平台上編譯這段代碼完全沒問題。。。見什么鬼了？？？
2. 錯誤原因分析
直接提示表明，欲生成JpegDecoder的可執行文件，需要鏈接動態庫libcodec_utils.so，但是找不到這個這個庫文件（自定義的庫文件），因此出現了這個鏈接錯誤提示。
3. 編譯知識回顧
一般理論常識是：-L參數指定了庫的目錄，-lxyz參數指定庫名。例如，本次鏈接的動態名稱為libcodec_utils.so，該庫位於上級目錄的libs文件夾下。
4. 疑問
我再次確認，庫目錄和庫文件都存在，Makefile寫的應該沒問題！況且在Linux平台下編譯通過了！但為什么在win下還是報錯？？？
5. 答案分析
由於使用的連接器ld.exe是運行在window系統下的，可能跟linxu平台下的使用方法稍有區別。
windows下查看命令行查看：ld --help，找到了一些鏈接參數信息：
其中，-l LIBNAME表示，要寫成-l libcodec_utils.so形式，而不能做一些省略，例如去掉“lib”和“.so”。（真正驗證時，還不是這種情況！！！）
在Linux平台下，顯示一樣的信息。可能是linux平台下，將參數"-lcodec_utils"自動補全為"-l libcodec_utils.so"形式。
6. 驗證結論
6.1 參數形式："-L../libs -lcodec_utils"
6.2 參數形式："-L../libs -l libcodec_utils.so"
注意，錯誤提示跟6.1的稍微有些區別，系統自動添加了前綴"-l"到庫名前，變成了"-llibcodec_utils.so"庫找不到。
6.3 參數形式："-L../libs libcodec_utils.so"
這是（目前驗證到的、可行的，其他方式或許有，但還沒找到）在windows平台下唯一的正確的參數。
6.4 鏈接系統的函數庫，可以使用"-lxyz"形式；若鏈接自定義的庫，不能使用該形式，庫名必須寫完整。
補充：-lxyz是使用的系統靜態庫（查看gcc編譯時的細節信息，使用-v參數，再去路徑下可以看到，系統自動添加了一些基礎庫用於鏈接，但這些基礎庫都是.a形式的靜態庫）。