本人在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形式的静态库）。